Inside the guts of a fiendish Internet Explorer 0-day attack The latest use-after-free vulnerability in Microsoft's Internet Explorer is being actively exploited in the wild. While this comes as a surprise to nobody, we all get to live in fear for a while until the software giant manages to get a patch out the door. In the interests of attempting to overcome a particularly nasty bout of …
Guess this is why the German Office of IT Security has <a href="https://www.bsi.bund.de/ContentBSI/Presse/Pressemitteilungen/Presse2012/Internet%20Explorer%20Warnung%2017092012.html>recommended people to stop using Internet Explorer</a>, in German. Of course, Microsoft Germany is playing down the issue.
Currently IE seems to be the target of choice, and has a pretty bad reputation.
I think it's not the first time the germans recommend to move away from IE
While it's true that microsoft takes patching more seriously then say adobe, they're not near the top of the list when it comes to patching browser security holes.
While it's true that microsoft takes patching more seriously then say adobe, they're not near the top of the list when it comes to patching browser security holes.
Who says Adobe doesn't take security as seriously as MS? That may have been true a few years ago but Adobe has had a clearly established patching system for Acrobat and Flash for several years now. Notable laggards in the consumer space are Apple and Oracle.
What do you expect?
Since Microsoft software dominates the world desktop PC usage, it is only to be expected to be the dominant target.
Now, for my personal view WRT using Microsoft software, I liken that to doing welding and grinding in an old, dried out wood frame building. It only takes one spark, or a bit of carelessness to send it up in flames. Linux, OTOH, is like doing thew same in a concrete block building.
In my `Mr. T` voice: "I Pity those fools" still using that Swiss cheese operating system.
Flames - the only appropriate icon.
(I had to resist the urge to refer to them as M$ - until now)
Yes and when a vulnerability is discovered and no patch is available and the vulnerability is known to be exploited in the wild, it's daft to continue to use the vulnerable browser because "surely some time in the future there will be a patch for it'. You wouldn't continue to use your car if the brakes broke down, because "surely at some time in the future I will have it repaired and it'll be safe to use it from then on", you would switch cars until it is fixed...
The recommendation of BSI to switch browser until the patch is released really is the only right thing to do here (as the EMET, MS' proposed work-around, is not available in German).
To bring an argument down to the point of absurdity is a sign you have no argument at all.
"You wouldn't continue to use your car if the brakes broke down, because "surely at some time in the future I will have it repaired and it'll be safe to use it from then on", you would switch cars until it is fixed..."
If the brakes failed (highly unlikely due to dual circuit systems employed for, ohh, the last 30 years) you would know the brakes had failed and naturally wouldn't use the car because thats a dangerous thing to do.
Exploits like this show no outward signs to draw attention to themselves and as such, are difficult to spot by joe public. Thats why they are successful. By the time this exploit is actually being widely exploited, it will be patched and MS released info on how to mitigate its effects as soon as they could.
I'm not switching from IE, not for this.....
You're kidding right?
Microsucks wouldn't know how to write secure code if you showed them. They don't give a rats arse about secure code. All they care about is cranking half-baked crapware out the door for unGodly profit. They can't even fix or secure their own code it's so bad...
You need to get in touch with reality.
Against fiendishly clever hackers any browser is vulnerable. It's daft to move browser for that reason... at least MS take patching security seriously.
Did you actually read the article? It pointed out that the vulnerability could be exploited by pretty much everybody and not just "fiendishly clever hackers". The intelligence of hackers is routinely overrated.
And it's not daft to move browsers for that reason: if I had a car that was unsafe to drive because of some design error (say putting the windscreen wipers on at 30 mph and then indicating right) the car would be recalled and I would be provided with a safe replacement. Except that this is not really possible in Windows because Internet Explorer is part of the OS, including the file system browser. This just goes to show that we need to divorce these kind of components more from the OS so that they can be replaced or at least disabled if necessary.
It took a lot of smarts to find the vuln is what I meant.
It took a certain degree of cleverness; "a lot of smarts" is a considerable exaggeration. Use-after-free vulnerabilities are well-understood. There are plenty of dynamic-analysis tools which can detect use-after-free conditions in running processes; even the Microsoft C runtime by itself can catch some of them. As Pott mentioned in the article, you can often find vulnerabilities like this simply by fuzzing the target. In other cases you do need to come up with execution paths that are likely to trigger them, but again there's a lot of literature and existing practice.
Some attacks do require extensive arcane technical knowledge and really clever exploitation of multiple vulnerabilities; Tavis Ormandy's #GP trap exploit against the Windows kernel (CVE-2010-0232) is an example. And similarly the first (public) discussions of now-common attack vectors like use-after-free and stack smashing (eg in Aleph One's classic article) often contain eye-opening innovative ideas, at least as far as public discussion goes.
But this looks like a straightforward Yet Another x-Type Attack. The researchers either stumbled across a use-after-free (probably aided by automatic detection) or conceived of a likely vector for one, and then they worked to exploit it. It's good, solid security work, but it's not groundbreaking.
Of course, this sort of problem is absolutely impossible in a system with automatic memory management, because the programmer has no direct access to pointers. For example, Java.
But Javascript itself uses automatic memory management. Obviously, they should have written their Javascript engine in C#. Turtles all the way down.
When a buffer overflow happens in Java, it's because of a bug in the JVM, not in the Java code. That bug is usually in the JIT. The JIT is complicated: probably more complicated than a static compiler, and most exploits run in browsers as applets, where attackers get to attack any bug in the JIT they choose.
That wouldn't be the case here - there would have to be a bug in the JVM, which in addition could be provoked by code in the Javascript interpreter. The odds of this are way smaller than just directly finding a way to provoke a bug in the JVM.
Of course, things would be even better if we used a statically compiled language with automated memory management. Popular languages in this category don't exist, but you can statically compile Java to C, and disable class loading.
"Popular languages in this category don't exist"
That statement is true, but there "exist" languages which are both memory-safe and efficient. You can have most of the efficiency and realtime capabilities of C++ without all the nasty Java properties such as voracious memory consumption and GC freezes. You can have your little command line program start up in less than 10 milliseconds.
More than 50% of all serious exploits in the CVE database are artifacts of the C and C++ languages. Real-world C and C++ programs will have them, because programmers are not superhumans. They don't live in a world of infinite funding and infinite project deadlines. Quite the opposite.
I designed a language called Sappeur and wrote a compiler (or call it a translator if you wish), which assures memory safety. Sappeur is (essentially) a memory-safe subset of C++ and adds some novel support for memory-safe multithreading. The compiler will generate C++ code to be compiled into machine code by GCC or msvc (or potentially any other modern C++ compiler). That took me about 10000 lines of C++ code. I do think the right people could prove correctness of a 10k LOC project, given reasonable time and budget.
But certainly the current version of the compiler will contain bugs. Still, I do think it demonstrates what is possible. It is another line of defence and given that hardware designers are not infallible creatures, we should look for any opportunity to add useful layers into the defence-in-depth armour. Is your MMU proven correct ? If not, will your sandbox ever work as promised ?
Actually, Sappeur programs could *remove* the need for MMUs and consequentially save cost and electric power.
See http://sourceforge.net/projects/sappeurcompiler/
I was indeed referring to the CPU's MMU. It is a quite complex piece of logic and memory cells. It needs a complex piece of handler code in the OS. And if the MMU contains a bug, chances are that conventional access control and sandboxes cannot be properly implemented.
Memory safe languages don't need an MMU, as all memory access operations are guaranteed to either fail deterministically or point to validly allocated memory. You could safely run a multi-user, multi-process operating system on an 68000 or 80286 CPU if you could assure that all programs were compiled by a trusted, memory-safe compiler. You would need a timer chip to generate interrupts for non-cooperative task switching, though.
Disposing of the MMU would potentially speed up the CPU, as the Address Translation does indeed take some time one way or the other.
"Once again demonstrating that everything based on the C language is the worst mistake in the history of computer software ..<br><br>
Detecting Bugs in Safety-Critical Code, Feb 2008
This post has been deleted by its author
I would love to claim all the credit, but in truth a significant amount must go to the inestimable Chris Williams (@diodesign). It was he who tipped me off to the source in the first place, he who serves as sub-editor, and indeed he corrected several mistakes I had made in terminology. (He’s a kernel programmer, so he knows things.)
You want a truly brainy vulture? Chris is your man. I’m just a bored sysadmin who decided to pick apart a zero day as an attempt to solve an insomnia problem.
Also: <pirate> yarrrrr </pirate>
Aye; I"m still waiting for an alternative to the EMCAScript family of languages to fulfill the role that Javascript occupies. What are the alternatives? ActiveX? (Oh FFS...) In-browser plug-ins? Flash uses EMCAscript, so it's out. What then, Java? .Net? SIlverlight? All of these are unappealing for a variety of different reasons.
Is there another language out there suited to client-side just-in-time compilation?
..I would probably take the FreePascal compiler and tweak/limit it until it generates memory safe code. Add a facility which limits direct operating system calls to the standard library. The latter would conceptually be very much like the J2SE standard library, especially regarding SecurityManagers. I would not implement all the "convenience" crap that pollutes J2SE, though. KISS - like the POSIX API, but of course everything controlled by some sort of SecurityManger.
FreePascal is both fast in compilation and fast/efficient in the resulting machine code. The Pascal language itself is well-suited for fast compilation. I still remember the extremely fast TurboPascal compilers and the efficient programs which it generated.
But alas, this does not resonate with the software engineering elite's pet concepts of fully automatic garbage collection, dynamic typing, functional programming, just-in-time compilation. So, expect to own a 10GB machine with a 3GHz processor that feels like that 16MHz 80286 PC. Surely some moron builds an IDE based on JS right now, after being so impressed by Government Office and Government Mail.
Javascript is a strange kind on language (no proper typing, for example) completely unrelated to Java. The only reason they have similar names is that Java was popular then and they wanted to have a sexy name for their contraption-running-in-the-browser. Technologically they have as much to do with each other as C++ and LISP.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
