RDP Proof-of-Concept Exploit Triggers Blue Screen of Death 128
mask.of.sanity writes "A working proof of concept has been developed for a dangerous vulnerability in Microsoft's Remote Desktop Protocol (RDP). The hole stands out because many organizations use RDP to work from home or access cloud computing services. Only days after a patch was released, a bounty was offered for devising an exploit, and later a working proof of concept emerged. Chinese researchers were the first to reveal it, and security professionals have found it causes a blue screen of death in Microsoft Windows XP and Windows Server 2003 machines. Many organizations won't apply the patch and many suspect researchers are only days away from weaponizing the code."
Missed the real story (Score:5, Informative)
How important is this? (Score:5, Informative)
The exploit doesn't allow unauthorized access or remote root. It only allows a denial of service against Windows XP and Windows Server 2003 products. It doesn't seem that Windows 7 and Windows Server 2008 are vulnerable. That really mitigates that risk. I have a Windows Home Server 2011 box that shouldn't be vulnerable because it's based on the WS2008R2 code base. Furthermore, there's already a patch for this bug. Therefore, if you're still running an old version of Windows that you neglected to patch, then your server might be crashed remotely. I don't think it's really that deadly or scary.
Re:Is this the hole that was patched one Tuesday? (Score:5, Informative)
Yes. The guy who discovered it reported it to both the TippingPoint Zero Day Initiative and to Microsoft, and sent them the packet that triggers the exploit. That exact same packet showed up in this exploit, meaning somebody either at ZDI or Microsoft or part of the MAPP program leaked it.
So much for responsible disclosure! Although as soon as I saw that TippingPoint had released a signature for this on Tuesday, I figured that would be enough information for people to figure out what was up. Leaking the exact packet made things even easier and quicker, though.
Gee, I do so love it when I get three days to deploy a critical patch throughout my entire production environment. That makes for some wonderful conversations with the admin staff, let me tell you!
Re:How important is this? (Score:4, Informative)
The sourcecode linked in the summary is just a proof-of-concept. A much more devastating payload, in principle, certainly can be delivered. MS says the vulnerability could allow arbitrary code execution https://technet.microsoft.com/en-us/security/bulletin/ms12-020
Re:How important is this? (Score:5, Informative)
That really mitigates that risk.
I question your definition of 'mitigates' sir. You are describing systems that are not vulnerable to this particular exploit. If you're infrastucture runs on Linux or Mac or oranges with electrodes sticking out of them, you havn't mitigated dick. You just aren't vulnerable.
Comment removed (Score:5, Informative)
Have fun (Score:3, Informative)
http://pastebin.com/nSp1Qxpi [pastebin.com]
If by purchase (Score:3, Informative)
You mean "download for free" then maybe. You realize that all Windows updates for the entire life cycle of the product are included with the purchase price of the original copy, correct? They do not charge a maintenance fee. They are also very up front about life cycle and end of life. 10 years minimum for all OSes. It can be (and often is) extended, but it is never less than that.
Re:How important is this? (Score:5, Informative)
With buffer overflows the way it usually works is that a buffer that is allocated on the stack (let's say, a temporary buffer where some user input goes to have something done on it) isn't properly bounds checked. Local function variables are on the stack. What is below them (on x86 and amd64) will be first the saved base pointer of the calling function, and then the return address of the next instruction in the calling function. So on a 32 bit arch, if we imagine the buffer is the first thing on the stack, the first 4 bytes of the buffer overflow will overwrite the calling function's saved %ebp register, and then the next 4 bytes you overwrite will be the return address of the calling function. When the function finishes and executes the RET statement, what happens is the address put on the stack by the CALL is popped off, and the program counter is set to this address.
Normally, this address is the valid return address, but in this case, where you've been able to overflow the buffer, it's whatever the 4 bytes were set to in the overflowing data. In a userland program, the program will usually crash with "Segmentation fault". In kernel land, you may get a kernel panic.
To exploit this, when the attacker overwrites the return address, if they can have this address point to their code instead, they can then gain control of the machine with whatever privilege level the process they are attacking has. Usually, the whole exploit is in the buffer that's overflowed, the attacker basically has to figure out what the address of their payload will be in the stack, and set the function's return address to this, and voila, they can execute arbitrary code.
A number of things have been done in recent years to frustrate this: randomizing the address of the heap and stack to make it harder to predict the address your attacking code will be at, and also making the stack and heap non-executable if the CPU supports it (or using a software emulation of the NX bit) so even if you do overwrite the return address with the address of your code, the program dies with "Segmentation fault" because the processor won't allow code to execute in that memory page.
Re:M$ Windoesn't (Score:2, Informative)
Are you serious? I guess I have been trolled:
$ someapp /usr/lib/libboost.so.15
Someapp can't find libboost.so.14
$ find / -name "libboost.so.*"
Um... I guess you didn't launch the application from it's starter script, OR use yum or a package aware system to install it, OR you used the "force" option.
In any of these cases - you should know what you're doing. Now -
# sudo ln -s /usr/lib/libboost.so.14 /usr/lib/libboost.so.15
# sudo lddconfig
has around a 80% (possibly greater) chance of fixing it anyway. Free advice.
$ yes QQ
QQ
QQ
QQ
QQ
QQ
^C
$
Un... yes, yes does that -- it's to be used like this:
yes | other stuff that will prompt
The reason it repeats is that it is expected that YES/yes/ok/OK, whatever, is what the application will keep requesting.
Practical use -- a FORTRAN application that uses the PAUSE statement. Run as follows:
grep $p cards > /dev/null && yes go | ./$p >> results;
Ok?
or my favorite one /boot perhaps run fschk without -j or -f? /boot ...
Couldn't find
root$ ls
grub boot
More details please -- what couldn't find /boot?
root$ :'( :'( )':
>)';
Couldn't find command:
The message depends on your shell. Nothing prevents putting newlines into filenames. Don't do it -- it makes the files difficult to type at the shell.
As none of these are security issues, or even bugs, they won't be "fixed" (nothing to fix here).
Now, I want to here more about the root kits. It is rather difficult to insert a rootkit into an SELinux system. Either a shell account would be needed, or a method to get around the service audits and denials. For example, Apache under SELinux is denied the ability to open files outside of its assigned subdirectory. Since this priviledge (or lack of) is inherited by the subprocesses, they also cannot access system files. Simply introducing code won't work. You would need to introduce kernel code. A buffer overflow may introduce code into Apache (also difficult, but possible), but that doesn't have the necessary security to broach the kernel.
Of course SELinux (MAC level security) is only really enabled for services, and not for arbitrary user level code. Simply separate the boxes physically, and don't put user dev accounts on the external facing server. Pretty much done.
And yes, I admit it, I've been trolled good.
Re:How important is this? (Score:5, Informative)