Slashdot Mirror

Downloads? Yes, all OSes and browsers are vulnerable, within limits (Javascript FTW). Downloads to arbitrary locations, arbitrary code execution, and local-user installation? Sort of. OSX is extremely vulnerable, and Windows & SELinux are mostly safe.

Low-IL processes ([1] [2] [3]) in Windows can't run or do much of anything (it can DoS the user, I guess, or read & transmit data). I said mostly safe because there are still weaknesses: unsafe application security/rules, communication with other protected but insecure processes or objects (including system services), driver exploitation via user-mode driver DLLs, et cetera.

May is such a definitive word. If I had a million dollars on a project, may is not going to cut it. And how much faith would you put into DEP? I don't: http://uninformed.org/?v=2&a=4&t=sumry

Also do you think M$ will come out and say that, "IE8 is exploitable, please use something else."?

I like the way Opera is doubly secure. Firstly it's a minority platform, secondly Opera are quick at patching vulnerabilities.

Opera kicks the ass of both Firefox and IE in my subjective 'elegance' benchmark too.

The only thing I wish they'd do is to run the Opera process in a low privilege protected mode on Windows like IE7+ uses on Vista and later. That would make it hard for any exploit to get from the browser process into your system.

It's not foolproof of course - see here (this exploit was fixed in Vista SP1)

http://www.uninformed.org/?v=8&a=6&t=pdf

Still nothing is foolproof. Defence in depth is still it good principle. Mozilla are considering it in FF too

http://mozillalabs.com/blog/2006/08/labs-ideas-to-investigate-survey-results/

http://www.uninformed.org/?v=8&a=4&t=sumry

Look like it was in the built-in Atheros driver.

Read this about Kapersky:

http://www.uninformed.org/?v=all&a=21

Love him or hate him Maynor did the right thing waiting to come out with his paper. Even with an NDA, anyone can publish something anonymously which he didn't do. Its sinful that corporations don't take this into consideration when dishing out credits to security researchers. As for the NDA, I'm going to guess it was probably with Atheros. For those looking for the page with Maynor's attack, its here OS X Kernel-mode Exploitation in a Weekend... Don't know why contributor didn't link it.

Here's a link to the actual paper.

And here's the important part:

Getting Code Execution

The result of this flaw is that many things beyond the Extended Rate buffer in the ieee80211_scan_entry structure are corrupted. In a traditional stack overflow, control of execution flow is obtained directly by overwriting an important value, such as the return address. The corruption caused by the ``Extended Rate'' bug is more complicated due to the apparent lack of adjacent control structures.

The most promising avenue for getting execution can be found in a function named ath_copy_scan_results. This function uses the fields that are overwritten to copy memory. An attacker can control the size of the copy and the source of the copy. In addition to crashing reliably on the same data, the size of the memcpy is two bytes wide meaning that up to 65535 bytes can be copied. Since the destination of the memcpy is a structure that ends with a function pointer, the hope is that enough data can written outside of the destination buffer to the point where the function pointer is overwritten. In this way, the next time the function pointer is called, the caller would instead jump to whatever address is now stored in the function pointer. In other words, this represents a two-stage overwrite. The first overwrite does not provide direct code execution, but it allows an attacker to create a second overwrite that will. The Beacon packet contains a number of buffers one can use for this second-stage overwrite. Thus, an overflow in one buffer in the packet (the Extended Rate IE) allows an attacker to control how a second buffer is copied (in this case, the Robust Security Network (RSN) IE). It is the copying of the second buffer that will permit code execution.

For example, CVE-2006-3648 and Exploiting the Otherwise Non-exploitable on Windows details how MS exeption handling in Internet Explorer can be exploited. Why should I have faith that the effects of this crash are not exploitable as well.

Additionally, just because something was initially reported as a crash, does not mean researchers won't find a way to later exploit it. Again, visiting the MS IE browser: Javascript window() issue in IE was publicly reported as a DoS in May 2005 and was ignored, until being reported as exploitable in November 2005. Why could not the same thing happen here?

Oh, I get it, Mr. LeBlanc at MS wants to tout his SafeInt class... well, being Office is closed source, vulnerability researchers cannot really examine this "security feature". I guess this offers MS a safety net to claim that these "features" are "3... meant it to blow up, and [are] clearly not exploitable", while protecting themselves from the vulnerability community finding exploitable flaws in the SafeInt code.

PatchGuard is already broken. Go read Skape and Skywing's article in Uninformed. For what it's worth, Ionescu's post mentions this explicitly.

Look, stop instigating.

I didn't know I was instigating anything. I was pointing out the lack of details in the original post. NT internals are of interest to me.

If you do a little bit of research as to who it is that cracked this you will see that he is more than capable of doing what he says he did.
I know who the author is and I respect him. He is not Dave Cutler, Linus or even Mark Russinovich (neither am I).
Adding ZwQuerySystemTime() or ZwOpenFile() wrappers to support a reversed engineered kernel isn't that impressive to me (Note, I haven't looked at ReactOS, I don't know if Alex added those system calls or not).

Per the latest article on PatchGuard over at http://uninformed.org/, Microsoft has disabled some of the hacks for PatchGuard in shipping versions of Vista. I'd like a summary of which hack worked (All I can test with is 2003 Server). No one has posted an article on hacking ci.dll, I'd like a little more information on that.

It seems to me that you have an agenda here, will you kindly fuck off?

No, I won't Fuck Off and your very rude. I have no agenda other than preventing Microsoft from owning my legally purchased Windows based computers. Its still my computer (my home, my car, etc). and I still have a right to dictate what programs get run. Yes I run Linux. Yes I have a few Macs.

It has been compromised, it was only a matter of time. end of story.
Agreed. Is the result reproducable? With the information in the orginal post, it is not. Again, I may have missed a link to a more detailed article.

Enjoy,

You are indeed correct about PatchGuard being purposely obfuscated (http://uninformed.org/index.cgi?v=3&a=3&p=1), but it certainly does raise the bar to rootkit writers, and ensures that earlier ones will not work with Vista.

Uninformed has a very interesting article Anti-Virus Software Gone Wrong that describes several ways AV vendors have messed up before when they have patched the kernel.

Uninformed has a very interesting article Anti-Virus Software Gone Wrong that describes several ways AV vendors have messed up before when they have patched the kernel.

On the other hand, isn't this flagged as an attempt to execute code on a data page?

The problem that wasn't. See http://www.uninformed.org/?v=2&a=4 . Also, wasn't this "back door" created well before DEP/NX was around on x86?

What I want to know is whether Wine is vulnerable to this design flaw that allows hardware enforced data execution protection to be remotely disabled by a clever buffer overflow (one that injects no code of its own, so cannot be prevented by DEP). I should mention that I submitted this story to Slashdot, but it was rejected.

There's also the already posted on Slashdot article on Uninformed Journal.