NULL Pointer Exploit Excites Researchers

Da Massive writes "Mark Dowd's paper "Application-Specific Attacks: Leveraging the ActionScript Virtual Machine" has alarmed researchers. It points out techniques that promise to open up a class of exploits and vulnerability research previously thought to be prohibitively difficult. Already, the small but growing group of Information Security experts who have had the chance to read and digest the contents of the paper are expressing an excited concern depending on how they are interpreting it. While the Flash vulnerability described in the paper[PDF] has been patched by Adobe, the presentation of a reliable exploit for NULL pointer dereferencing has the researchers who have read the paper fascinated. Thomas Ptacek has an explanation of Dowd's work, and Nathan McFeters at ZDNet is 'stunned by the technical details.'"

Comments

Aha!

[Rik Sweeney]

So you CAN get something from nothing!

Re:Aha!

[naveenoid]

Nothing to see here, move along...

Re:Aha!

[lawn.ninja]

Something from Nothing? I'm sure Plato is rolling over in his grave as we speak.

The crux of the exploit:

[Ethanol-fueled]

"...Not this time. Flash forgets to check that allocation failed, a ludicrously common error. It then uses that pointer with an offset controlled by the attacker. NULL isn't valid. NULL plus 1024 isn't valud. But NULL + 0x8f71ba90 is, as is NULL + N for any N that addresses valid memory.

To this address, controlled by attackers via wild offset, Flash writes a value that is also controlled by the attacker. This is the write32 pattern: a vulnerability that gives the attacker the means to set any one value in memory to a value of their choosing. Game over.

The exploit doesn't actually get to offset an arbitrary number of bytes from 0. A complicated set of conditions constrains the address it writes to and the value it gives it.

The the actual write occurs via a structure offset. Flash is hardcoded to translate your offset into another number. Working offsets, as it turns out, will be greater than 0x80000000, and will be evenly divisible by 12 after 4 is added to them. Note: I thought I was hardcore when I wrote shellcode with no lowercase letters for the IMAP vulnerability in the '90s.

That's not all. The value that Flash will write to the wild pointer isn't totally controlled by the attacker either. It's cast up from a 16 bit integer to a 32 bit integer, and has another variable subtracted to it. This is the point in the report that I started giggling uncontrollably, embarassing myself at the coffee shop...

...The net result of this silliness is that it's hard to do what attackers normally do with a write32 vulnerability, which is to clobber a function's address with a pointer back to their buffer, so that their shellcode is called when the clobbered function is called. So Dowd's exploit takes things in a different direction, and manipulates the ActionScript bytecode state.

To wit: his exploit must (because he's messing with us) corrupt the Flash runtime, rewrite it to execute his trojan, and leave it running steady as if nothing had happened. Meaning:

--His modification to the verifier can't break existing instructions. --His bytecode has to swap values into the stack instead of clobbering them directly. --Portions of his shellcode have to run as both Flash bytecode and an X86 first-stage shellcode boot.

Two fun details:
First, even though IE and Firefox use different Flash builds, the addressing inside them is compatible. The exploit works in both places.
Second, Flash isn't compiled with ASLR. So the attack works on Vista.
Mass casualty. Go Flash!"

Re:The crux of the exploit:

[slapys]

Dude. You are wise beyond your years. I hereby dub thee: the sensei of security.

Re:The crux of the exploit:

[Ethanol-fueled]

Ha, don't thank me, I only RTFA's and pasted the bullet points from one of the articles. I'll gladly accept the karma, though :)

Re:The crux of the exploit:

[jo42]

So you would ban knives from the kitchen because they are sharp and can cut you?

If you think Flash sucks now, wait until it is written in 100% Java.

Re:The crux of the exploit:

[martinmcc]

That is just silly, and demonstrates a lack of understanding of programming. High level langauges with built in checks and safties are very useful in a lot of situations, but they do not meet the needs when precision and control of the underlaying hardware is required. Whether flash needs this level of control I do not know, but plenty of applications do.

And, oh yes, WTF!!OMG!! - '...should be banned...'. Yeah, ban the filthy programming languages that don't babysit the programmer. While we are at it lets ban corners, very dangerous.

Re:The crux of the exploit:

[Stellian]

Except this is not a NULL pointer exploit. It's rather irrelevant how exactly you obtain the address needed to overwrite your target: in this case, you add up your controlled offset to a NULL base obtained after a failed malloc(), but it's just a rare circumstance. I ask you this: if the malloc call did not fail, wouldn't he still had control over the offset ? That's the major vulnerability right there, and he added the integer overflow to get a NULL pointer from malloc in order to stabilize the exploit.
A NULL pointer vulnerability means accessing things like object.member, where object is NULL, and the offset of member is fixed at compile time and/or small enough to fit in the few hundred unused memory pages that the 0 address is surrounded with. Any access in that arrea causes a page fault that can't be recovered from, and the OS terminates the application.
This is not a new class of exploits, just a very complex and creative one.

Re:The crux of the exploit:

[Rogerborg]

The default C++ new does throw an exception rather than returning NULL, but don't let your ignorance of the language stop you from decrying it.

Re:The crux of the exploit:

[pla]

Assuming that Flash is made in C or C++, here is another very vivid example of why these languages should be banned.

You do understand that all those nasty loosely-typed pointer-based exploits you and others disdain in C, exist because C nicely mirrors how the actual hardware handles similar concepts?


If failure of allocation threw an exception, instead of just returning null, there would be no problem.

And if programmers would check that the allocation succeeded, we would also have no problem.

In your hypothetical "safe" language (C#, for example), I can't count how many times I've seen system calls wrapped in a try/catch to hide the exception, then carry on pretending the call worked just fine. Guess what? SAME DAMNED PROBLEM!



Don't blame the pipe-wrench for making a poor hammer. Blame the craftsman too lazy to find a hammer.

Re:The crux of the exploit:

[hey!]

The kitchen? No. The Nursery? Might be a good idea.

Re:The crux of the exploit:

[Anonymous Coward]

That's right, because those old languages like C++ don't support those new-fangled exceptions do they? We should all be writing in Java or C# and running our nice, safe code inside nice, safe virtual machine runtimes which do things like bytecode validation and address range checking. It's well known that virtual machine runtime implementations never have bugs in them that could be exploited.

Wait, what was this article about again?

Re:The crux of the exploit:

[Anonymous Coward]

So you would ban knives from the kitchen because they are sharp and can cut you?

If you think Flash sucks now, wait until it is written in 100% Java. And just what do you think the JVM is written in?

Because underneath it all, the computer runs its native instructions. Period. The GP is a fucking moron if he thinks "throwing an exception" is a cure-all for insecure code. One guy develops a complicated NULL-pointer exploit that's valid in ONE virtual machine, and the GP reflexively supports banning C and C++.

Probably because he's too stupid to code properly without having some virtual machine interpreter holding his dick.

If you don't understand the consequences of the code you write, you're incompetent and in over your head. Banning specific languages won't improve your comprehension.

Re:The crux of the exploit:

[spir0]

Assuming that Flash is made in C or C++, here is another very vivid example of why these languages should be banned. look, there's really no nice way of saying this, but ... well, you're an idiot.

what should be banned are those useless coders who think that a language should do everything for you, thus making you lazy and bloated like your code.

remember: you are in control of the machine, not the other way around.

Re:The crux of the exploit:

[gmack]

Don't blame the pipe-wrench for making a poor hammer. Blame the craftsman too lazy to find a hammer.

A more accurate analogy would be "don't blame the hammer because your shelf is uneven since you didn't bother to use a level.

Splintand friends will show up NULL pointer bugs very quickly even when using it's most liberal setting.

Of course the average C programmer hasn't progressed beyond not fixing compile warnings so they haven't gotten to the splint part yet. Sometimes I wish "-WERROR" was GCC's default.

Re:The crux of the exploit:

[Simon Brooke]

That is just silly, and demonstrates a lack of understanding of programming. High level langauges with built in checks and safties are very useful in a lot of situations, but they do not meet the needs when precision and control of the underlaying hardware is required. Whether flash needs this level of control I do not know, but plenty of applications do.

Furthermore, if you ban the low level languages, what are you going to write the high level language's byte-code interpreters in? You generally need a bit of low level stuff to bootstrap your virtual machine.

Re:The crux of the exploit:

[Waffle Iron]

Furthermore, if you ban the low level languages, what are you going to write the high level language's byte-code interpreters in? Why, turtles of course. Turtles all the way down.

Re:The crux of the exploit:

[hotfireball]

Assuming that Flash is made in C or C++, here is another very vivid example of why these languages should be banned.

Yes! You are right! It all should be done in Perl!! Did anybody ever saw such sort of bugs in Slashdot?!

*hides*

Re:The crux of the exploit:

[chthon]

No need to to rewrite it in Java, but one should consistently use exceptions.

If a function is used which should be checked for its return value to see if it succeeded or not, then it should be wrapped inside a new function, which always does the check and throws an exception if nothing has succeeded.

No, you cannot do it in C, but you should be able to do it in C++.

I did this with my own Perl libraries. I try to make sure that everything I use throws an exception when an error situation is encountered.

Re:The crux of the exploit:

[samkass]

Actually JDK6u10 promises to be pretty competitive with Flash while also providing the huge advantages of Java. They've completely re-implemented how Java interacts with the browser and cut the minimal initial bootstrap down to a little over a megabyte (for the first time it's invoked) and sped up initialization time immensely. In short, applets could actually start working rather well for once soon.

Re:The crux of the exploit:

[dargaud]

I don't know either flash or VMs in general, but in order for the attacker to return a fake value from a malloc call, shouldn't the attacker already have control to libc (in C) or to the internals of the VM in that case ? Meaning he already can do whatever he wants...

Re:The crux of the exploit:

[n0-0p]

Yes, thank Tom Ptacek, the Hagrid of the security world. And I state that with nothing but respect for Tom.

Re:The crux of the exploit:

[ultranova]

That is just silly, and demonstrates a lack of understanding of programming. High level langauges with built in checks and safties are very useful in a lot of situations, but they do not meet the needs when precision and control of the underlaying hardware is required. Whether flash needs this level of control I do not know, but plenty of applications do.

The only things which need precise control of underlaying hardware are the parts of device drivers which actually control the hardware (as opposed to sanitizing input or talking to the rest of the system). Flash isn't a device driver, it is an utility program.

And, oh yes, WTF!!OMG!! - '...should be banned...'. Yeah, ban the filthy programming languages that don't babysit the programmer. While we are at it lets ban corners, very dangerous.

Absurd analogies aside, doesn't this bug - and thousands upon thousands just like it - prove that your average programmer needs to be babysat ?

Besides, just why are you so hostile towards the of having the computer automatically make correctness checks that stop this kind of thing from happening, and as a side effect lessen the burden of the programmer considerably ? Is it some form of geek machismo - "Real Men manage their own memory" ?

Re:The crux of the exploit:

[AmaDaden]

If you don't understand the consequences of the code you write, you're incompetent and in over your head. Banning specific languages won't improve your comprehension.

Fun fact! IDIOTS WILL NEVER STOP WRITING CODE. So preventing the web from using any language that is not nerfed would be a good plan to protect everyones personal info. Even if you don't use the internet the govt will. See this story for an example... Oklahoma Leaks 10,000 Social Security Numbers

Re:The crux of the exploit:

[ultranova]

what should be banned are those useless coders who think that a language should do everything for you, thus making you lazy and bloated like your code.

People who can't be bothered to use the Shift key shouldn't blame others for laziness.

Sure, we could ban all but programming superstars. Of course, if we did, then Flash, Firefox and Linux would neve have gotten written in the first place, since the price of coding would be far too high for anything but megacorporations to pay for. Given this, wouldn't it be better to have the computer compensate for the inherent laziness of human beings by putting as much automation as possible into the programming language ?

Besides, having the computer automatically do things like memory management behind the scenes means that you don't have to do them in your code, making it simpler, not bloated.

remember: you are in control of the machine, not the other way around.

Yes. And since the machine is faster and more accurate than you, why not make it take care of the details like memory management ?

Re:The crux of the exploit:

[mysticgoat]

Don't blame the pipe-wrench for making a poor hammer. Blame the craftsman too lazy to find a hammer.

A worker who uses a pipe-wrench as a hammer is no craftsman.

A writer who would blur the distinction between the work of a trained and ethically responsible craftsman and a somewhat trainable monkey is a poor wordsmith.

But after getting beyond that criticism, I believe I have an understanding of what I think the parent post was attempting to say. And I do not disagree with what I think was the intended point: In the great majority of cases, poor code is not the product of poor tools; it is due to inadequate training that leads to abuse of tools that are adequate to do a good job when used by someone that knows their craft.

Gawd, that last paragraph is pedantic and just plain awful. Need. More. Coffee.

Re:The crux of the exploit:

[T.E.D.]

remember: you are in control of the machine, not the other way around.

If you are coding in C, you won't be in control of the machine for long. :-)

Re:The crux of the exploit:

[Flaming_cows]

The way they force a NULL return from malloc is by using a value that's valid when interpreted as a signed type (which the code checks), but causes a massive attempted allocation of memory (one that will invariably fail) when interpreted as an unsigned type, as malloc uses it. This can then be used to overwrite part of a static table of instruction lengths stored somewhere around 0x80000000 which causes the bytecode verifier to interpret a set of Actionscript bytecodes differently from how they are actually executed later on. Nothing else on the machine has to be compromised in advance.

Re:The crux of the exploit:

[springbox]

Visual C++ 6.0 returns NULL instead of throwing an exception when memory allocation fails. Apparently.

Re:The crux of the exploit:

[martinmcc]

"The only things which need precise control of underlaying hardware are the parts of device drivers which actually control the hardware (as opposed to sanitizing input or talking to the rest of the system). Flash isn't a device driver, it is an utility program."

As mentioned, my knowledge of Flash internals is close to zero, so I have no comment to make on that, my comment was that there are plenty of occassions when it is needed - expecially when you get out the the PC centric idea that all computers have a keyboard mouse and nice GUI.

"Absurd analogies aside, doesn't this bug - and thousands upon thousands just like it - prove that your average programmer needs to be babysat ?"

No, its proves that programming is still a art/practise/whatever you want to call it in its infancy, with still plenty of leassons to learn. People have been building structures for thousands of years, yet mistakes are still made (leading to direct loss of life). That does not mean tools such as hammer and nails should be banned.

"Besides, just why are you so hostile towards the of having the computer automatically make correctness checks that stop this kind of thing from happening, and as a side effect lessen the burden of the programmer considerably ? Is it some form of geek machismo - "Real Men manage their own memory" ?"

I'm not at all, and don't think any was applied. I currently program a lot in .NET, and am really impressed by the language. However I do (in OS development) have plenty of need to use a low level language, such as assembly or C. My hostility is towards reactionary comments from someone who obviously does not understand what he is talking about.

Re:The crux of the exploit:

[T.E.D.]

That is just silly, and demonstrates a lack of understanding of programming. High level langauges with built in checks and safties are very useful in a lot of situations, but they do not meet the needs when precision and control of the underlaying hardware is required.

Perhaps true for most such languages, but Ada just as good at doing low-level hardware banging as C. Actually its better in a lot of ways. For instance, its a lot easier to specify exactly what record fields go where in memory with Ada. It supports memory mapping and overlays too, which you have to hack in C using pointers.

The "safeties" can even be removed if you need them to be. The important thing is that they are there by default and you have to go out of your way to get rid of them, whereas in C its the opposite. Thus a lazy programmer or one who misses a case ends up with a safer program than they intended, rather than one with a security hole. Perhaps these days C has the wrong defaults?

Re:The crux of the exploit:

[sconeu]

And VC6 is 10 years old, 3 versions old, and predates ISO/IEC 14882:1998(and 14882:2003).

Nobody should be using VC6 anymore.

Re:The crux of the exploit:

[electricbern]

Darn, I'll have to starting doing this RTFA thing to stack some karma.

Re:The crux of the exploit:

[Abcd1234]

In your hypothetical "safe" language (C#, for example), I can't count how many times I've seen system calls wrapped in a try/catch to hide the exception, then carry on pretending the call worked just fine. Guess what? SAME DAMNED PROBLEM!

Yeah, which is why you *don't catch exceptions you can't recover from*. It's a basic design tenant, and it's *easier* to do than fucking it up by incorrectly handling the error. Basically, in a language like C, you have two options:

1) Check for the error and handle it, possibly incorrectly, leading to the problem you describe.
2) Ignore the error, and your program could misbehave.

An exception-based language gives you these options:

1) Catch the error and handle it, possibly incorrectly, leading to the problem you describe.
2) Ignore the error, and the program violently terminates.

Gee, which one do you think is better from a security standpoint?

Nope, sorry buddy, but *any* language that uses exceptions as the model for error indication will be superior, as far as security goes, to a language like C. The real problem with the GP is that that also includes C++ (which, at least in a decent compiler, throws an exception if new fails to allocate a chunk of memory).

Re:The crux of the exploit:

[multipartmixed]

> Sometimes I wish "-WERROR" was GCC's default.

Unfortunately, there are [rare] times when it is necessary to write code which generates compiler warnings. The most common one I experience is cast-align, for perfectly reasonable reasons (_I_ have made sure the cast promotion is correct, but it is impossible for the compiler to know).

In these cases, it would be nice to have an __attribute__() which says "Suppress this warning". Maybe even which forces the programmer to type in some explanatory text (since I comment every single warning that comes out of my checked-in code).

But for those coders out there who produce code with reams and reams of warnings... gads. And for these which don't, yet "fix" things like const-correctness warnings with stupid casts (instead of fixing the root of the problem) .. Shame on you!

Re:The crux of the exploit:

[T.E.D.]

The default C++ new does throw an exception rather than returning NULL, but don't let your
ignorance of the language stop you from decrying it.

Hold on a minute there, Captain Ivory Tower. Perhaps *your* C++ compiler does that. Mine (VC++, probably the most used compiler on the planet) does not.

With VC++6 it returns NULL. With newer versions it *sometimes* will throw an exception, but it depends on which libraries the linker happened to pull in first. See this link for more information.

Re:The crux of the exploit:

[ostiguy]

The problem with Adobe is that they are Microsoft, circa 1999: adding features to drive version upgrades without thinking about security implications.

Is there a flash version that takes advantage of the security features of vista? No.

Are there delta patches for the ginormous acrobat reader install? No. Does this cause end users to decline updates? Yep. Every month or 2, another 15+ MB update, that will prompt the end user to reboot.

Re:The crux of the exploit:

[martinmcc]

I certainly wouldn't want to get into a religious war about what languages are better for a given situation. Undoubtedly there are better languages and frameworks for particular situations than C. However, C has a lot going for it - it has been around for eons in computing timeframes, has a huge amount of knowledge and experience around it, huge amounts of libraries etc. Also, the very fact it can be 'dangerous' can be seen as a benefit - I know that having learnt C early in my programming developed greatly helped make me a better programmer, and I find I am constantly explaining concepts such as stacks, pointers, garbage collection etc. to programmers who have just learnt a higher level language, where the concepts are still important but not directly needed to use them (why would someone understand garbage collection if they have never had experience of programming without it?).

My real issue with the parent poster is the reactionary use of the term 'ban' - I would allow, and probably agree with, use of low level languages should be discouraged when a higher level language could do the same or better job, but really that situation pretty much already exists anyway. If he made the point that flash itself would be better off being written in a different language, and backed it up with some evidence, that could have been informative, However he does not even know what language flash was written, then calls his assumption a 'vivid example of why these languages should be banned'. This, in my mind, is pure sillyness.

Re:The crux of the exploit:

[Anonymous Coward]

The JVM has proved that everything written in pure Java is 100% immune to buffer overflow/overruns. You simply are NOT going to see a 'null exploit' for a Java JVM.

This statement is simply false. Java is written in C/C++ and has had a number of memory corruption vulnerabilities identified in it. Further, all those Java objects are passed around as references, so I certainly wouldn't discount someone finding an exploitable NULL pointer dereference.

I do agree that Java makes such bugs a lot less likely, because they can occur in only the platform and JNI modules. However, it does not make you immune.

Re:The crux of the exploit:

[spir0]

Besides, having the computer automatically do things like memory management behind the scenes means that you don't have to do them in your code, making it simpler, not bloated. I disagree. your source may not be bloated, but the binary at the end will be.

making programming simpler only means that simpler coders will be coding.

Re:The crux of the exploit:

[ultranova]

The argument was against lazy idiots. Have we really degenerated to the point where anybody who is not a lazy idiot gets to be called a "superstar"? Sad.

No, the argument was against people who "think that a language should do everything for you, thus making you lazy and bloated like your code." That only leaves people who have a passion for doing things the hard way, rather than simply using programming as a tool for solving problems. In other words, everyone but the superstars.

Simply because you don't want to do something which the computer can do for you automatically doesn't make you a lazy idiot. But even if it did, my point still stands: requiring higher quality programmers would make programming more expensive.

Re:The crux of the exploit:

[ultranova]

I disagree. your source may not be bloated, but the binary at the end will be.

If the automatic system is good, it only adds checks where needed (and doesn't recheck things already checked), so it doesn't add any checks the programmer wouldn't. And it can, in fact, leave out checks a programmer would have to make, since the compiler/VM knows which functions call which, so it can track the checks accross function calls and leave them out if the parameters were already checked by the calling function, which a human can't, at least not reliably and without making the program a nightmare to maintain.

Besides, didn't people say the exact same thing to defend the use of hand-optimized assemblers against such inefficient bloated crap like C, and C against C++ ? Even if it was true, it didn't really matter, because computers keep on getting faster while humans don't, so moving more and more of the work from the programmer to the programmed is inevitable; you simply won't stay competitive otherwise.

making programming simpler only means that simpler coders will be coding.

You make that sound like it was a bad thing. It isn't. Making coding simpler and thus accessible for larger number of people is a good thing; it makes computers more useful to them.

And of course, the less effort you need to put towards the details, the more you can put to the big picture; consequently, removing the grunt work from programming makes even good programmers more productive, since they'll be using less of their time for said grunt work.

Re:The crux of the exploit:

[leuk_he]

If you read teh article you read that flash uses bytecode, just like jave, and that a part of the exploit was exploiting one byte of cehcks on the bytecode.

If you know java/JVM like he exploited flash bytecode, you can exploint null derefeneces just like he did with flash in java.

JIT, with all kind of crazy optimizations will make it only worse.

The problem is that you can break out the virtual machine(/application) if you knwo it well enough.

Even virtualisation will not fix this. Look at the vmware 1.05 release notes and you see that there was a exploit where the client could write in the ENTIRE host file system.

Re:The crux of the exploit:

[naasking]

I can't count how many times I've seen system calls wrapped in a try/catch to hide the exception, then carry on pretending the call worked just fine. Guess what? SAME DAMNED PROBLEM!

Indeed, but these programmers are failing to heed age-old wisdom: detect errors at a low-level, handle them at a high level. Return values don't encourage this program structure, where "correct" code ends up being quite hairy due to all of the error passing.

Exceptions allow low-level errors to propagate to higher-level code which can abort the request, and retry it at a later date. That's what those programmers should have done: just let the error propagate. This is especially true of memory exhaustion errors. Exceptions are better than return values for larger programs. So the misuse of exceptions is a programmer problem, not a problem with the mechanism itself.

Re:The crux of the exploit:

[99BottlesOfBeerInMyF]

This is the point in the report that I started giggling uncontrollably, embarassing myself at the coffee shop...

For anyone who has met Tom, this is an amusing image. He's a big guy who (at least when I knew him) often dressed like he was on his way to a Siouxsie and the Banshees concert.

Re:The crux of the exploit:

[naasking]

what should be banned are those useless coders who think that a language should do everything for you, thus making you lazy and bloated like your code.

While I can sympathize, that's just uncalled for. There are good reasons for introducing higher-level constructs which handle the aspects of programming that humans are bad at (memory management for instance), thus freeing them to handle the aspects of programming that they're actually good at (algorithm design).

Anyone who thinks otherwise is honestly deluded. C/C++ have their place in some low-level systems, though I would argue that Ada is probably a better choice in almost every case, but its prevalence in so much high-level application software is just negligent IMO. Software written in C/C++ will always have vulnerabilities unless it's subject to costly security audits, which almost no one will do, or the C/C++ compiler itself injects code to prevent such attacks (as many research projects are currently attempting to do).

Re:The crux of the exploit:

[ClamIAm]

[Ban knives from] the kitchen? No. The Nursery? Might be a good idea.

Oh wow, this is a good analogy: the average computer user unfortunately is much like a little kid. And I don't think saying that is condescending in the least.

I think of it this way: the average computer user is excited because they learned how to work the Internets on their machine. They're much like a kid who just learned how to ride a bike, but hasn't crashed hard enough (no pun intended) to be conscious of the dangers.

Re:The crux of the exploit:

[ClamIAm]

Fun fact: even with the nerfiest language on the planet, you'll still have exploits.

Re:The crux of the exploit:

[IthnkImParanoid]

You're correct of course, but I've read many a forum post containing the assertion that VC6 is the better/best IDE even if the compiler is outdated. I like VS2008 and CodeBlocks just fine, but I can see their point. All the more reason to decouple the compiler from the IDE.

Re:The crux of the exploit:

[RAMMS EIN]

``And if programmers would check that the allocation succeeded, we would also have no problem.

  In your hypothetical "safe" language (C#, for example), I can't count how many times I've seen system calls wrapped in a try/catch to hide the exception, then carry on pretending the call worked just fine. Guess what? SAME DAMNED PROBLEM!''

Not quite. First of all, there is a marked difference between having to write extra code to handle an error, and having to write extra code to ignore an error. The easier the language makes it to do the right thing, the more often the right thing will be done.

Secondly, there is an important point to be made about (type-) safe languages. In a type-safe language, the abstractions provided by the language canont be broken. Your program will only ever do what the source code says it does. Contrast this with C, where various ways exist to make the program do something utterly different from what the source code says. C's lack of type safety is at the root of entire classes of exploits, all of which simply aren't possible in type-safe languages.

Re:The crux of the exploit:

[T.E.D.]

However, C has a lot going for it - it has been around for eons in computing timeframes, has a huge amount of knowledge and experience around it, huge amounts of libraries etc

Agreed on most of that, but be careful about the libraries. What a lot of C coders like to call "C libraries" are really just plain "libraries" that can be used just fine by any compiler that uses the system linker.

My real issue with the parent poster is the reactionary use of the term 'ban'

I tried to read the ancestor post, but it appears to have been modded down to hades. Judging from the heat of the responses, probably quite rightly. The problem is that a lot of the responses "oversteered" a bit.

Using C when you don't have to should not be considered a "best practice", but talk of talk banning is simply unhelpful. Nobody likes to be dictated to, least of all software developers.

Heck, the DoD even tried it for a couple of decades. Just look how well that worked out. Just about as well as Prohibition did for killing alcohol usage. Ever met someone from that generation that doesn't drink? I haven't.

Re:The crux of the exploit:

[SL Baur]

The GP is a fucking moron if he thinks "throwing an exception" is a cure-all for insecure code. One guy develops a complicated NULL-pointer exploit that's valid in ONE virtual machine, and the GP reflexively supports banning C and C++. Crudely put, but correct. TFA outlines clearly the logic errors in the bytecode interpreter that make this possible. There's a period of time between input validation and usage that can be exploited and it is. Duh. There's an unwise distinct difference between how the input validator and the executor treat invalid input that can be exploited and it is. Duh.

I thought this was going to be something interesting like the 0 page exploit described in Bach's Unix System V Internals book where on certain kinds of hardware, it was possible to read NULL and near NULL pointers without the machine faulting allowing access to kernel data (which worked on my M68K Unix System V box at the time). Instead it's just a sloppily written byte code interpreter bug.

Re:The crux of the exploit:

[sconeu]

That's true, I once posted that I'd kill for the VC6 IDE with the VC7.1 compiler.

I guess I've just gotten used to the VC7+ IDE now.

Re:The crux of the exploit:

[w000t]

isn't there an exit() function in c?

Re:The crux of the exploit:

[petermgreen]

the problem is of course that the "nerfed" languages have to be interpreted or compiled by something.

Both java and flash are vm based enviroments intended to allow untrusted code to run safely. Both of them are also highly complex and as such almost certainly have exploitable bugs.

Re:The crux of the exploit:

[Flying Scotsman]

or the C/C++ compiler itself injects code to prevent such attacks (as many research projects are currently attempting to do [llvm.org]).
Or perhaps the C/C++ compiler itself will inject code to allow such attacks.

Re:The crux of the exploit:

[petermgreen]

Agreed on most of that, but be careful about the libraries. What a lot of C coders like to call "C libraries" are really just plain "libraries" that can be used just fine by any compiler that uses the system linker.
Sure if you are willing to spend lots of time turning the output of a tool like h2pas into something that will actually compile and reimplementing stuff that the library author implemented as macros rather than real functions.

Re:The crux of the exploit:

[naasking]

Excellent point! We'll never be sure without proof-carrying code, which raises the bar for attack to extraordinary levels.

Re:The crux of the exploit:

[Abcd1234]

That's called "[catching] the error and handling it". Just because the error handling code is "exit()", doesn't change the fact that it's explicit error handling code that must be included in order for the program to work correctly. But in an exception-based language, you don't have to do *anything* to get safe behaviour.

Re:The crux of the exploit:

[The End Of Days]

And it's been true with every version. Fulfilled promises count as a plus, you know.

Re:The crux of the exploit:

[petermgreen]

In your hypothetical "safe" language (C#, for example), I can't count how many times I've seen system calls wrapped in a try/catch to hide the exception, then carry on pretending the call worked just fine. Guess what? SAME DAMNED PROBLEM!
I don't know about C# but in java null pointers are a lot less dangerous than null pointers are in C.

In java the worst a null pointer will do is give you a nullpointerexception.

In more traditional languages which support pointer arthmetic or pointers to raw arrays things are much worse. Doing pointer arithmetic on a null pointer is essentially equivilent to doing an integer to pointer conversion.

Re:The crux of the exploit:

[Mr Z]

The first C compilers were written in assembly. What's GCC written in? C. More interestingly, what's Gnat (GNU Ada) written in? That's right. Ada.

How's that you ask? It's the very bootstrapping process you refer to.

As long as you can compile to machine code, there's no reason you ever need to write it. If you have a new machine, just make a cross-compiler in a high level language. Sure you need to have a native code generator at some level to createe the lowest level code that runs on the new machine, but that native code can be generated from as high a level language as you like once you have a sufficient software stack.

Of course, such bootstrapping has its own problems.

Re:The crux of the exploit:

[Mr Z]

Unfortunately, there are [rare] times when it is necessary to write code which generates compiler warnings.

These get MUCH less rare when you crank up the warning and optimization levels. For example, the following idiom generates a warning in recent GCC versions if you turn -Wstrict-overflow on:

for (i = 0; i < len; i++)
. . if (foo[i] == blah)
. . . . break;
if (i == len)
. . return -1; /* not found */

This tends to generate the following warning:

warning: assuming signed overflow does not occur when simplifying conditional to constant

*sigh*

Re:The crux of the exploit:

[Abcd1234]

Great, you've handled one case. Now what about realloc(), calloc(), free(), open(), read(), write(), etc, etc, etc?

Now suppose you want to allow the error to trickle up to some top-level code, where you can clean up after yourself and maybe generate a nice log message. How would you do that? Now how would you do it for code in a reuseable library? Now imagine you have code using the library, and it realizes it *can* handle the error, and would like to retry. How would you accomodate that without going in and modifying the library?

See, while you *can* do things in C, they're almost always horribly inconvenient, hackish, error prone, quite often unsafe, and everyone ends up rolling their own, which means yet more untested code with no miles on it. *Or*, you could use a language that provides facilities to make these things easier (and exceptions are just the tip of the iceberg). Why do you think so many people have worked so hard to replace C? Because, except for a few niche areas, it's *not* the best tool for the job anymore.

Re:The crux of the exploit:

[T.E.D.]

If you're still using a version of VC++ older than 2005 in 2008, there is something seriously wrong with you

...like you are still supporting products you delivered more than 2 years ago. I agree totally. I don't know WTF we are thinking over here. Everyone knows modern software is deliver-and-abandon. What's with this place I work at anyway?

(note. For those of you who don't happen to be using a sarcasim-sensitive web browser, pretend the above statement is outlined in lavender).

Re:The crux of the exploit:

[mindriot]

I ask you this: if the malloc call did not fail, wouldn't he still had control over the offset ?

Yes he would, but it's a slight bit more difficult to foresee what address malloc will return to you. So you don't really have control over where you'll be writing to. But if you can force a NULL dereference, you know exactly where in memory your offset will land you.

Re:The crux of the exploit:

[T.E.D.]

VC++ has been throwing an exception on failures of new() since version 7.

...in *some* cases. Not in some others.

doubt there are many apps left that are still compiled with VC6. I think you are exaggerrating the VC issue

VC6 is what we use here. We're planning on transitioning away in 6 months or so, but we work in an industry where things have to be maintained for decades, and we have lots of tool and hardware dependancies that all have to be satisfied before we can migrate to new platforms. We don't do it when its avoidable. Perhaps this is somewhat unusual, but I know we aren't unique.

The C++ clearly states that failure of new must throw std::bad_alloc, so the original poster was wrong.

I agree that the original poster was wrong on quite a few levels, including that one. However, C++ is not a language where you can say "the standard says X, so that's the end of the matter", because some of the prime compiler implementers do not care much about the standard. You *have* to look at what the compilers being used to develop the apps are actually doing.

Re:The crux of the exploit:

[spir0]

Besides, didn't people say the exact same thing to defend the use of hand-optimized assemblers against such inefficient bloated crap like C, and C against C++ ? well, now that you mention it, let's see.. a stripped binary of cat (written in C) on my current system weighs in at 18,148 bytes.

My version of cat (written in asm) weighs in at 596 bytes.

Even if it was true, it didn't really matter, because computers keep on getting faster while humans don't, so moving more and more of the work from the programmer to the programmed is inevitable; ah yes, the old, computers-have-so-much-power-we-don't-need-to-care line. in general, this may not be an issue, but there are some people who take this to the extreme, and some programmers who are either so bullheaded, or so retarded, that if they see any loss of performance, the fault is always that of the hardware. Because computers should be able to cope with their terrible code. I mean, come on, this is the 21st century, right?

You make that sound like it was a bad thing. It isn't. Making coding simpler and thus accessible for larger number of people is a good thing; it makes computers more useful to them. yes, I'm sure the legions of people writing spyware, viruses, and other malware for windows would agree with you.

And of course, the less effort you need to put towards the details, the more you can put to the big picture; consequently, removing the grunt work from programming makes even good programmers more productive, since they'll be using less of their time for said grunt work. absolutely, the virus writers are more productive than ever. back when viruses had to be written in super optimised assembly so that you could jam a couple of bytes into a bootblock to call a nasty wee sub, then continue on as if nothing had happened was a real art.

now what? you can get virus construction kits. why think for yourself when someone else can do that for you?

Re:The crux of the exploit:

[spir0]

There are good reasons for introducing higher-level constructs which handle the aspects of programming that humans are bad at (memory management for instance), thus freeing them to handle the aspects of programming that they're actually good at (algorithm design). assuming they are. :)

but I hear you. yes, to a point I agree with you. writing X completely in assembler is something I'd not wish on my worst enemy. High level languages are without a doubt the primary reason computers have shifted from the domain of the ubergeeks, but it's the complacency in those languages I can't abide.

Re:The crux of the exploit:

[naasking]

Understood. Tools to assist in profiling still have a long way to go to help the hapless developers.

Re:The crux of the exploit:

[w000t]

sorry, you're right of course. i misread your post as if you were saying that a program in C can't be (violently) terminated in case of error.

Re:The crux of the exploit:

[pla]

Now what about realloc(), calloc(), free(), open(), read(), write(), etc, etc, etc?

I won't claim that C works best for every purpose - Don't make this into a holy war, I only meant that the underlying problem comes from the coders, not the languages they use.

But to answer your question, you can wrap every failable library function, if you want to. You can even find premade wrapper libraries/classes to make C/C++ behave like exception-oriented languages (the latter actually has some exception abilities already, actually, but not to the extent you appear to prefer).


Now suppose you want to allow the error to trickle up to some top-level code, where you can clean up after yourself and maybe generate a nice log message. How would you do that?

You register an atexit function, and take care of whatever cleanup and logging needs to happen.

For finer granularity, you can write a wrapper (or several variations) around "exit()" that do what you want.

Or, you can actually handle the error, which IMO should always happen, even if you can't recover from the error. And there, this issue comes down to a matter of what the programmer does rather than what the language does. When a program throws an exception rather than popping up a nice human-targetted message telling me what went wrong, that tells me that the programmer simply didn't expect the error in question to happen. And if he didn't expect that error, who knows what else he didn't expect.

Re:The crux of the exploit:

[pla]

I don't know about C# but in java null pointers are a lot less dangerous than null pointers are in C.

As long as we assume that the VM has no bugs.

The FP article specifically points out the untruth of that assumptionl; and if you consider this "the last one", I have a bridge for sale...

I mentioned that C mirrors how the hardware behaves for a reason other than the performance. When you write for a JVM, or the ActionScript VM, or whatever safety net you prefer, your code still ends up doing something at the same unsafe hardware level you so disdain.

Re:The crux of the exploit:

[Rogerborg]

I'm sorry, I thought we were talking about C++. I have no idea what it is that you - or Microsoft - think you're talking about, but it's not C++.

Re:The crux of the exploit:

[Kalriath]

C# throws a NullReferenceException ("Object reference not set to an instance of an object").

Hell, even Visual Basic handles it ("object variable or with block variable not set").

Re:The crux of the exploit:

[ralphdaugherty]

I don't know either flash or VMs in general, but in order for the attacker to return a fake value from a malloc call, shouldn't the attacker already have control to libc (in C) or to the internals of the VM in that case ? Meaning he already can do whatever he wants...

      I don't know why this is rated Interesting, but the answer is no.

  rd

Re:The crux of the exploit:

[master_p]

Precision and control of the underlying hardware has nothing to do with the safety of a programming language. They could have used ADA, for example, or Erlang, which is used in embedded devices.

Re:The crux of the exploit:

[master_p]

The article says they used malloc to allocate memory, but don't let your ignorance of the article stop you from decrying my comment.

Re:The crux of the exploit:

[master_p]

Thank you. These little details seem very unimportant at first, but they are the basis for the huge problems IT is facing...

Re:The crux of the exploit:

[master_p]

You do understand that all those nasty loosely-typed pointer-based exploits you and others disdain in C, exist because C nicely mirrors how the actual hardware handles similar concepts?

ADA has pointers, but it does not let you screw things up like that. The idea that a language that allows control of the hardware should be unsafe is silly.

And if programmers would check that the allocation succeeded, we would also have no problem.

Why let the programmers do it and risk failure, when the machine can do it better?

In your hypothetical "safe" language (C#, for example), I can't count how many times I've seen system calls wrapped in a try/catch to hide the exception, then carry on pretending the call worked just fine. Guess what? SAME DAMNED PROBLEM!

I never said that C# should be used.

Re:The crux of the exploit:

[master_p]

You don't need a virtual machine to run safe code. Advanced type systems have been developed that do not allow you to screw things and be as good as C in performance and control.

Re:The crux of the exploit:

[master_p]

Perhaps I am an idiot, but those people that deny the fact that C is one of the reasons that IT has huge problems today are also idiots. There are vastly safer programming languages than C that are equal to C when it comes to low-level programming. Microsoft has an entire operating system in works based entirely on software isolation with safety provable at compile-time, for crying out loud.

The reason we have such programs is that C allows for partial functions. For example, the type of malloc is:

malloc : int -> void* | int -> null

But the 2nd branch of the malloc's type is quietly suppressed, leading to the problems mentioned in the article.

Re:The crux of the exploit:

[ggvaidya]

Why, turtles of course. Turtles all the way down. Logo?! At last, the year of Lisp on the desktop is nigh!

Re:The crux of the exploit:

[multipartmixed]

Wow, you may have just convinced me to upgrade GCCs to get better warnings.

I got nailed 3-4 weeks back with a very strange bug, where I foolishly assumed that "1 32" was 0 (32-bit sparc). Unfortunately, it turns out to be 0xffffffff. Argh.

Re:The crux of the exploit:

[Mr Z]

Ah yes, the famously undefined "shift by 32." I can't see which direction you're shifting (your << or >> got eaten). On one of the DSPs I work with (TI's C6000 family), it has a 40-bit shifter and so looks at the lower 6 bits of the shift amount. Most other architectures only look at the lower 5 bits of the shift amount. This occasionally leads to amusing bugs.

As for the idiom above that generates the warning... I really don't know what circumstance it's warning about, except perhaps if "len" is less than 0—say, INT_MIN or something. But still, since it's an equals comparison, overflow shouldn't matter on the target architecture. Maybe it matters on machines with saturating arithmetic, but then perhaps the optimizer shouldn't make those kinds of optimizations on those architectures.

--Joe

Re:The crux of the exploit:

[Abcd1234]

I only meant that the underlying problem comes from the coders, not the languages they use.

I disagree. "Safe" languages are safer because they make the default case safe. In C, the default case is unsafe (and this is true for much of the language and standard library). The former makes it easier for the programmer to do the right thing. The latter makes it easier for the programmer to do the wrong thing. And every programmer can benefit from a language that makes safe programming easier... after all, no one is perfect.

Or, you can actually handle the error, which IMO should always happen, even if you can't recover from the error.

Absolutely not! By doing this, you do one thing: introduce additional code that's exceedingly hard to test, for no good reason. It reduces the coverage of your tests, and just increases the odds you'll introduce a bug.

It's a simple rule: If you can't handle the error, and your language gives you a mechanism for passing the issue on up the stack, you should *use it*. 99 times out of 100, you can't do anything about it, anyway, and anything you do attempt will probably be wrong.

When a program throws an exception rather than popping up a nice human-targetted message telling me what went wrong, that tells me that the programmer simply didn't expect the error in question to happen.

No, what it tells you is that something exceptional happened. Something that the program couldn't handle, and so it threw up it's hands and said "I don't know what happened, but you should probably look into it". That's a *good* thing. The last thing we need is more code hiding errors, or doing the *wrong* thing when it should just be aborting and alerting the user that something strange is going on.

But to be clear, I'm not saying programmers should ignore *all* errors. If you can recover from an error, you should do it as soon as possible. But if you can't, don't even try! The problem is, unsafe languages like C don't make that easy. Of course it *can* be done (Java is written in C, after all, so it must be possible), but it sure ain't easy or pretty or standardized.

Re:The crux of the exploit:

[spir0]

Perhaps I am an idiot, but those people that deny the fact that C is one of the reasons that IT has huge problems today are also idiots. I think this follows along with...

The reason we have such programs is that C allows for partial functions. ok, so let me get this straight. you believe that a language which allows you to do something retarded is inherently the fault of the language when you actually *do* said retarded thing?

is that what you're saying?

let me make this clear: no language is at fault for anything in the IT industry. that distinction is placed squarely on all the idiot programmers who do stupid things with those languages. it's your job to understand the constraints and abilities of the language and work within that.

or, put another way -- a gun allows me to blow my cock off. Am I going to do that? uh. no.

Re:The crux of the exploit:

[master_p]

The reason computers exist is because they automate tasks...therefore, I want my programming language to automate as many things as possible. If a thing can be automated and my language does not do it, then it's the language that's at fault, and not me.

C leaves a lot to be desired when it comes to automating tasks; its shortcomings are numerous and have nothing to do with system programming.

Binary blobs

[should_be_linear]

Some years ago I had many binary proprietary blobs on my computer: SUN Java browser plugin (now OSS), Adobe Acrobat (don't need it any more, OSS alternatives are equal now), nVidia driver (still needed but solution is on the way -> looking forward to switch to ATI as soon as GPL drivers get there), MS media codecs (don't need it any more, Flash ate MS' streaming video pie). Now, only Flash player remains that I don't see replacement in OSS world in foreseeable future. Add to it security concerns, 64-bit version and it clearly becomes major PITA of Linux desktop users. Doesn't look it will change any time soon.

Re:Binary blobs

[CRCulver]

There's always Gnash. FWIW, the only Flash applications that I can't get to work with Gnash are YouTube-like video players, and I usually prefer to download those as .flv files straight to my computer with a Firefox extension.

Re:Binary blobs

[ardor]

I recommend to watch this one: http://en.wikipedia.org/wiki/Gnash

Re:Binary blobs

[vux984]

Add to it security concerns, 64-bit version and it clearly becomes major PITA of Linux desktop users. Doesn't look it will change any time soon.

Actually, its just a major PITA, period.

Flash isn't any more secure on windows.

And there's no 64-bit version for windows either.

Windows x64 even ships with a proper 64-bit Internet Explorer 7, but it doesn't support flash. So to view flash in Windows x64, just like on Linux x64 you need to use a 32-bit web browser. Pretty sad.

And it goes without saying the a 64-bit build of Firefox (Minefield) doesn't work with flash on Windows x64 either.

Re:Binary blobs

[AvitarX]

I use nsplugin wrapper and didn't even have to configure it (it was automatic).

It still likes to lockup and crash my browser, but it likes to in Windows too. And it usually is an add.

Re:Binary blobs

[atlastiamborn]

What I'd really want was some way to have both the proprietary flash player and gnash installed side by side and an easy way to switch between them. That way, you could just use gnash until you hit some file that it has trouble with and then just switch over.

Re:Binary blobs

[maxume]

If you are using Firefox, you might like Flashblock:

https://addons.mozilla.org/firefox/433/

Flash objects become nice friendly play buttons that you activate only when you choose. There is even a whitelist if there are sites that you visit just for their flash content.

Re:Binary blobs

[dintech]

"Gnash is dead, you're on your own."

Re:Binary blobs

[martinw89]

Just wanted to mention that Swfdec is coming along quite nicely also. It already plays all the popular FLV video players. Plus it has some cool features, like a universal "play" button on all the media it handles so you don't get assaulted by flash.

Re:Binary blobs

[Peter La Casse]

What I'd really want was some way to have both the proprietary flash player and gnash installed side by side and an easy way to switch between them. That way, you could just use gnash until you hit some file that it has trouble with and then just switch over.

I do that on my Kubuntu desktop. I use Konqueror with gnash as my default browser, and when it can't handle something I right click and select "open this page in Firefox" (which has the adobe plugin installed.)

Re:Binary blobs

[Anonymous Coward]

Do you care about Flash as anything other than an audio/video container? If that's all you need, then just use mplayer to play the video. I have been doing this for a long time, and it works wonderfully. It is far better than using any Flash player. There are Greasemonkey scripts to automate the whole process for Youtube now too.

Re:Binary blobs

[raddan]

Except that even Linus Torvalds can't seem to get swfdec running correctly.

Re:Binary blobs

[alan_dershowitz]

Incidentally I just installed Gnash on my fresh install of Xubuntu PowerPC 8.04 Beta, and it would play Youtube videos. Minorly buggy, but it worked.

Oblig

[Anonymous Coward]

NULL to see here, move along to 0x80000001 please...

The Art of Software Security Assessment

[MadMidnightBomber]

(book by Dowd, McDonald, Schuh) is well worth a look: http://taossa.com/index.php/author/mark/

Re:The Art of Software Security Assessment

[n0-0p]

Yeah, that book has become bible on vulnerability research. There's really nothing else comparable if you want to understand how vulnerabilities work, and how to find them. The odd thing is that it's style is more directed at programmers than security people.

Re:The Art of Software Security Assessment

[n0-0p]

I don't think that it has much at all on automating the workflow, which makes sense to me. Tools and fuzzers are changing so fast that they aren't well served by books. I already have a few books on those topics, and they've all grown stale within a year or two.

The books that I keep around for a long time are the ones that really cover the essentials. I put this book in that category because it explains vulnerabilities more clearly and thoroughly than anything else out there. And it lays out all the process and tricks for finding security bugs. That's the kind of stuff that will be relevant for years.

Cross platform? I don't think so.

[Viol8]

FTA: "is not far off being cross platform "

Err , I'm sorry but how exactly do they expect x86 code to run on Sparc, or PA-RISC or PPC? etc etc. Even on the same architecture but a different OS all the interrupt vectors and API address calls will be different. Sounds like they're got a bit over excited to me. Or maybe I've missed some complex details of the exploit.

Re:Cross platform? I don't think so.

[lisaparratt]

For x86: you use the Flash APIs to determine which actual platform you're on, load the code appropriate for the platform, and then use the exploit to execute it.

Re:Cross platform? I don't think so.

[Alioth]

The only cross platformness it needs is browser cross platformness. 95% of desktops run Windows on x86. Since I suspect Flash doesn't get updated as often as Windows or Firefox (and I suspect many users don't even update those) this is going to be quite an effective way of making a botnet.

The original article already has Russian trackbacks on it.

Re:Cross platform? I don't think so.

[bcmm]

I think they mean that the flaw they exploit exist on multiple platforms. The actual payload to be executed would of course have to be re-written.

Re:Cross platform? I don't think so.

[Anonymous Coward]

It relies on Flash. Flash is only available in five versions - Windows / x86 (as an ActiveX control, and a Netscape plugin), Linux / x86, Mac OS X / PPC, and Mac OS X / x86.

The exploit already works on two (both Windows versions) out of those five. With some tweaking, it'll work on two more. With some additional work, it will also work on the last one.

The neat thing is that this single exploit can be used to break into any browser, on any operating system.

Anyone still believe that the secure browser from a month or so ago was overkill?

Re:Cross platform? I don't think so.

[Viol8]

Well that rather depends on how different CPUs and platforms handle deferencing of invalid values doesn't it not to mention any platform specific code that flash itself may contain underneath the exploitable code.

Re:Cross platform? I don't think so.

[utnapistim]

Yes, but will it run with Flashblock?

Re:Cross platform? I don't think so.

[unapersson]

You missed out the ARM version that runs on the Nokia N800.

Re:Cross platform? I don't think so.

[NatasRevol]

And coming soon Mac OS X / Arm!!

Please?

Re:Cross platform? I don't think so.

[Kalriath]

You're missing several. The definitive list from Adobe is:

* Win32 (ActiveX / NS Plug-in) / x86
* OS X / x86
* OS X / PPC
* Linux / x86
* Solaris / x86
* Solaris / SPARC
* Windows Mobile / ARM
* HP-UX (built by HP, not Adobe)

And if I'm not mistaken there's one built for Symbian that they don't list here too.

Always check your return values!

[Anonymous Coward]

The moral of the story is a point that many of us have already been making for years: check the return value of malloc. I've had lots of arguments over whether or not it's okay to omit that and let your program crash for the poor sap who hasn't got any heap left. Unfortuantely a common attitude is, "the program is screwed anyway at that point, so who cares?"

The fact that Flash is doing all of these bytecode things also of course makes it more interesting. The first article linked seems to suggest that that makes the exploit really difficult (probably true), but it sounds like it also made it... well... possible.

Re:Always check your return values!

[somersault]

Thanks for the tip :p I don't think I've used malloc for a few years personally, but this is a useful thing to keep in mind for future applications. I wonder how many /.ers know that it can even be exploited in this way - I certainly don't know much about security exploits.. I'd have no idea how I'd go about exploiting buffer overflows and null pointer exploits like this, though I can imagine it would be a fun exercise :P

Re:Always check your return values!

[Tony Hoyle]

On a modern OS you have to work hard to make malloc fail. OSs will grant memory requests far above the amount of physical memory, and will even overcommit the virtual memory on the theory that you're not going to use all of it anyway.

The only way I've seen to get it to consistently fail is not on low memory but by asking for ludicrous amounts like 4GB at once on a 32bit system. Try it - get your system into a low memory condition and execute a few mallocs.. they don't fail - the OS merely continues to increase virtual memory and swap more and more.

Re:Always check your return values!

[siride]

You have to have contiguous sections of address space large enough for the allocation. If you're on Windows, and you've already allocated, say, a gigabyte of heap space, plus whatever is taken up by your code, stack and loaded libraries, then even a relatively small request might end up failing, even if there is enough memory available. There is just no free chunk large enough to satisfy it. In fact, on a 32-bit system, I can say with 95% confidence that you could never allocate, say, 1GB in a single allocation and have it succeed. There are probably smaller numbers that work here as well.

Re:Always check your return values!

[Anonymous Coward]

On a modern OS you have to work hard to make malloc fail. OSs will grant memory requests far above the amount of physical memory, and will even overcommit the virtual memory on the theory that you're not going to use all of it anyway.

The only way I've seen to get it to consistently fail is not on low memory but by asking for ludicrous amounts like 4GB at once on a 32bit system. Try it - get your system into a low memory condition and execute a few mallocs.. they don't fail - the OS merely continues to increase virtual memory and swap more and more. You talk about "a modern OS", and then describe how WINDOWS uses its swap file.

"A modern OS" will most likely have fixed-size swap partitions.

Re:Always check your return values!

[maxume]

So instead of breaking, a modern OS just stops working?

Neat.

Re:Always check your return values!

[jvkjvk]

On a modern OS you have to work hard to make malloc fail.

The only way I've seen to get it to consistently fail is not on low memory but by asking for ludicrous amounts like 4GB... So, in other words, you don't have to try very hard at all?

Re:Always check your return values!

[ari_j]

I think that per-process or per-user memory quotas/limits are a more likely way to get malloc() to fail than the system running out of memory. But I also don't know if Windows has those.

Re:Always check your return values!

[jorghis]

If you are looking for a way to get to fail for the purpose of testing your code check out the alloc hooks.

http://www.delorie.com/gnu/docs/glibc/libc_34.html

glibc isnt the only implementation that does something like this. You can write a simple little function that will just keep a counter of the number of times alloc has been called and then call back to the regular alloc until the counter hits a certain value and then force it to fail by returning NULL. Just do some analysis on your code and then use enough different counter values that you can be reasonably sure you have covered all the paths. Or you could turn the hooks on/off depending on where you are in the code being tested.

A lot of people will wrap their alloc calls in a != NULL or something similar but never test it. If you are working on a large system it is a virtual certainty that someone somewhere has made an error in the code that is supposed to clean up after the return from a failed alloc call. Untested alloc clean up functionality causes a lot of errors. Having difficulty forcing it to fail is a terrible excuse for not testing your code.

I cant count the number of times I have seen a programmer do something like the following:

for(i=0; ibig_number; i++){ ....
      if((array[i]=malloc(something)==NULL){
              return failure;
      } ....
}

Just checking your return value is not enough. You have to make sure you clean up everything and test it. It is very rare that you can just throw a "return failure" statement in there and be ok. Usually things are significantly complex that you cant get away with just assuming that the error case works. For example many programs will keep enough memory seperate from the alloc that they can still perform an operation like saving the file and exiting cleanly. However it is very common to see this functionality fail to work correctly because the guy writing all the other code left the data structures in some bad state due to not testing alloc failures well enough.

Re:Always check your return values!

[jorghis]

ugh, should have pressed preview, let me correct that code snippet:

for(i=0; ibig_number; i++){
            if((array[i]=malloc(something))==NULL){
                            return failure;
            }
}

Forgive my syntactical errors please, the slashdot text box wont report the errors for me the way a compiler will. :)

Re:Always check your return values!

[multipartmixed]

> Unfortuantely a common attitude is, "the program is screwed anyway
> at that point, so who cares?"

I have to admit, I'm one of those guys with that attitude.

On the other hand, I generally only bother not checking the return value if I'm _really_ sure the program is going to crash _soon_ (like within 2-3 lines and no branches after the failed malloc).

Things like

a = malloc(sizeof(int));
*a = 3;
 
a = calloc(sizeof(*a));
a->member = value;
 
a = alloc(sizeof(*a));
memset(&a, 32, sizeof(a));

...I would all expect to be safe. OTOH,

a = malloc(64);
someFunc(a);

...I would insist on a check unless someFunc() _explicitly_ documented its behaviour in its contract *and* I was able to deal with all of its error conditions, even those cause by passing NULL a.

That said, my second example of what I consider is safe is possibly exploitable under some wierdly wild circumstance. It would involve VERY low memory addresses being mapped in. Or, a VERY large struct. This is a good article, it's made me think of something new.

Re:Always check your return values!

[n0-0p]

Sorry, but you're wrong. A typical Win32 application has maximum address space of 2GB, regardless of available swap. This is by far the most common scenario. Another poster mentioned that you must also consider the largest available chunk of contiguous memory, which is almost always smaller. In practice, I haven't seen most real-world applications successfully allocate more than 1GB of contiguous memory after they've been running for a little while.

The next thing you need to understand is how to get a value larger than the allocation cap. Many applications simply accept an unbounded length for some fields, which presents no barrier. If there is a bound, there are still a variety of ways to cause a failure. For example, in a browser you can use JavaScript operations to fragment the memory until the target size is no longer available. You also need to look at how a value is used after it's accepted. In the case of this particular vulnerability, the bound is defeated by later operations that result in a large integer. If you're not familiar with these types of arithmetic vulnerabilities I suggest you take a look at the sample chapter from Dowd's book: http://www.awprofessional.com/content/images/0321444426/samplechapter/Dowd_ch06.pdf

Regardless, it's often quite easy to force an allocation failure.

Re:Always check your return values!

[jesup]

There are tools for memory failure checking. In the old Amiga days, we had several tools such as "memoration", which would fail arbitrary/random allocations, with all sorts of patterns (from a specific library, of a specific size, every Nth, random, etc). Typically we'd test the OS, libraries and applications with both random failures and increasing values of N for every Nth. In later versions of the OS, we could run the entire system with random allocation failures on for long periods and the only result was occasionally a user action would fail, and the OS certainly wouldn't fail.

Similar tools exist for Linux and I assume Windows, though I suspect they're used a lot less.

Re:Always check your return values!

[Fnord666]

...but by asking for ludicrous amounts like 4GB at once on a 32bit system.

That is exactly what the exploit does. By exploiting a flash length value that is validated as signed, but used as unsigned, Dowd was able to cause the dynamic allocation to request a massive amount of storage in a single call with the intent of having it fail.

Re:Always check your return values!

[shutdown -p now]

The only way I've seen to get it to consistently fail is not on low memory but by asking for ludicrous amounts like 4GB at once on a 32bit system.

It would seem that it's precisely what's being exploited here, and the way to get that too-large value is by exploiting overflow behavior on signed/unsigned conversion.s So here comes a second lesson: always check for overflow on all operations involving values derived from input!

Re:Always check your return values!

[ralphdaugherty]

On a modern OS you have to work hard to make malloc fail. OSs will grant memory requests far above the amount of physical memory, and will even overcommit the virtual memory on the theory that you're not going to use all of it anyway.

      Although this is true, the first step of the ActionScript VM (Flash) exploit was to create a malware Flash script that had a negative number for number of tags, or something of the like, which reliably causes the VM malloc processing for that parm to return NULL.

      This was not a "gee, if a malloc ever returns NULL, this will work" exploit, but an exploit that starts out causing malloc to return NULL, then use the NULL pointer.

  rd

Re:Always check your return values!

[armb]

In the case of this exploit, it's because of a failure to check user-supplied data, and giving a negative number as the alleged length of an array causing overflow to a ludicrous amount.
If you are mallocing a size you calculated entirely yourself, and it fails, it's likely to be because something is already corrupt, and it will be harder to turn into an exploit, but it's still good practice to check.

Re:fubar

[Hal_Porter]

This interesting because he's exploiting a malloc fail. The gory details of exploiting ActionScript is also cool because it has a bytecode verifier and he manages to get around it. It really is a lot more high tech than a typical stack buffer smash against a badly written C application, and that is important because everyone should hopefully have updated that sort of code to be exploit free by now. And stack checked binaries and data execute prevention, AMD's "Not Execute" bit, make those more likely to end in process death than arbitrary code execution.

Finally because it works on both IE and Firefox and Flash has such a huge installation base it should be able to target a very high percentage of current machines. Larry Osterman called it "The way the world (wide web]) ends"

Mind you, if Address Space Layout Randomisation was turned on in the Flash executable on Vista, exploiting this hole would most likely (255 times out of 256) lead to a browser crash rather than arbitrary code execution, so it's not like the last few years work on security has been totally wasted. At the moment it's not and you will get owned reliably. Adobe have published an update, so it's a good idea to download it.

http://www.adobe.com/support/security/bulletins/apsb08-11.html

Back when I was reading about security someone said that buffer overflows that execute code on the stack were first generation exploits. Second generation would be more subtle stuff like this.

Re:Big deal

[Trouvist]

It can run anything. If you read the paper, it explains that once you desynchronize the interpreter from the validator, you are running x86 instructions. One might have to tailor the exploit to work differently on Linux/Unix than on Windows due to the different executable addressing schemes, but once that is determined you are in business.

not boring

[Anonymous Coward]

null pointer's are very common errors in software, but are extremely hard to exploit. It almost never happens. This is why it's interesting.

Re:not boring

[Culture20]

null pointer's are very common errors in software [Pedantic]null pointers are very common in software; NULL is a common value to assign to pointers. Null pointer dereferencing (attempting to dereference a pointer which has as its value NULL) is a very common error in software which has an extremely simple fix. Check ur pointers for NULL [/Pedantic]

Re:boring?

[starling]

It's an impressive hack, or series of hacks rather, so I wouldn't say boring. The interest is not that the exploits are anything new (they aren't), but in the difficulty of pulling it off.

hmm.

[apodyopsis]

finally a decent opportunity to ask...

"does it run Linux?"

or in other words from TFA Win32 Firefox/IE prone to this technique, I'm assuming the code injection would only work on the target OS, no? I mean the CPU is specific, but also to work seamlessly you need to script it to to the target app. So it does not work on another processor (PPC etc) but also it would not work on any other application - so as the Linux binary is different then you are safe (until that one is attacked, but part of the security of Linux relies on the smaller audience is not so attractive a target). But what if it worked on a Win32 DLL that was being emulated under Linux such as some of the codecs? Any thoughts? correct me!

And, just out of curiosity, I'm kinda wondering how long it took Mark to work this one out.

Re:hmm.

[keysersoze_sec]

does it run Linux? Definitely. Just need to massage some asm code to make it fit.

part of the security of Linux relies on the smaller audience is not so attractive a target Dude, if you feel safe just because you're running Linux, you could be surprised some day. Plus, the "smaller audience" is not so small anymore, thanks to Ubuntu and the like. On the other hand, projects like PaX and grsecurity, constant code reviews and bug monitoring do make Linux a pretty safe place.

Re:hmm.

[ubernostrum]

As others have pointed out in reply to similar questions, there probably isn't one single piece of injected exploit code that'll work on any operating system. However, Flash continues running after the injection, and can detect what platform it's running on, so an in-the-wild exploit could simply come with a selection of code to inject and choose what to do based on information Flash hands to it.

Re:hmm.

[Lumpy]

"does it run Linux?"

Yes if you install the Wine libraries.

Actually if the malicious code was written by someone with skill instead of the typical cracker wannabe and written in assembler it would run on ANY X86 platform regardless of the OS installed if it could use the same vector to get in. Granted it takes a bit more in the assembler program to then look and see, "Ok am I in a windows box? no, Linux? no, OSX? BINGO! Infection started....."

It really would not be that hard to do if you had the education.

Re:hmm.

[JasterBobaMereel]

The difference is that in Linux the browser runs as you and so can only affect your own files ... (Which you have backed up?) On Windows the browser runs as an elevated user and so can affect much more ...

If however it can run arbitary x86 code directly all bets are off and operating system security is basically non-existent except at the hardware level ....

Re:hmm.

[dysfunct]

If however it can run arbitary x86 code directly all bets are off and operating system security is basically non-existent except at the hardware level ....

What exactly do you mean? Any x86 code will either pretty much have to use syscalls to do anything useful and thereby run under normal user privileges or - as you said - will cause exceptions because it's not running in ring 0 and can't do anything privileged on the hardware side of things.

Re:hmm.

[beuges]

Since when does the browser run as an elevated user on Windows? A browser on Windows, even IE (which some people still idiotically believe is tied into the kernel or something similarly retarded), runs as the user that launched it. And with Vista, the browser actually runs with _fewer_ privileges than the normal user account. Or at least IE does. /. reported a while ago that Microsoft was working with the Firefox developers to help them run with reduced privileges also.

Re:hmm.

[Alpha830RulZ]

I think this is a naive assumption about the risk to Linux users. I manage several Linux servers. While I log into them rarely, when I log into them, I often use Firefox, because I'm usually troubleshooting something. That usually involves surfing forums, which not uncommonly have flash based ads on them. This is a predictably activity, and, because I'm fixing something, I'm usually running as root.

I doubt that I am unusual in this pattern of behavior, so this is a fairly serious risk.

Re:hmm.

[mr_mischief]

You might want to consider sudo or consider having two separate sessions open, one root and one not. You can manage the multiple sessions with screen or with multiple virtual consoles. You might also consider not installing Flash and not enabling JavaScript on your browsers installed on servers.

Re:hmm.

[Alpha830RulZ]

I install noscript on the browsers, and know how to keep out of trouble. My point was merely that it's naive to assume that the Linux user model always protects you.

The measures you take are smart. However, when I'm on one of these servers, it's usually because something is wrong, and I'm in a hurry to get it fixed, so taking exotic protection measures are usually the last thing on my mind. I suspect my situation is not unusual in that respect.

Re:hmm.

[Kalriath]

No, not troll. The browser does not run in any form of elevated context, it runs as the user. In Vista, it runs sandboxed away from the user. This is fact, and if you don't think so you should reply as such. "-1 Troll" is not a synonym for "-1 I Disagree, and Would Like to Silence Your Anti-Groupthink"

Re:hmm.

[mr_mischief]

It's a little extra effort, but using the root account only for the exact changes you're going to make isn't exactly "exotic". The difference in security really is worth it.

I'm not saying I'm always 100% tied to those practices myself, BTW, although I try to be. It's really second nature after a while, especially if you're using sudo. There's still that odd moment when I log straight in as root and go when I'm in a great hurry, but that is the exception. It actually takes mental effort now for me to log into a box as root rather than as a user account and using sudo or su.

Re:hmm.

[bigstrat2003]

Mods, please mod parent post up, it is factually accurate and not a damn troll.

Excited Researchers

[PseudoLogic]

The stuff we geeks get excited about... *sigh* We're hopeless, aren't we?

Yes, but if your pointer is NULL

[smittyoneeach]

...you'll need a little Viagra first.

flashblock ftw!

[verin]

Thankfully the flashblock addon was just updated to support firefox 3 beta 5. Since I only allow flash to run from a few sites, I'm not worried about any such exploit.

I've been a big fan of flashblock, ever since realizing that most flash developers assume 100% volume is mid range, and I assume 50%, and every flash website without volume controls rips through my ears like a buzzsaw.

Re:flashblock ftw!

[LiquidCoooled]

I am also a huge fan of flashblock (I helped code up some bugfixes for it in a prior version), but be aware of its limitations.

Flashblock does not prevent flash running.
It removes existing flash from the DOM AFTER it has already been inserted and sometimes the initialization of the flash starts before it is replaced by the clicker.

Granted, most of the time it is removed before the ping time of the destination server with the SWF, but not always.
(Notice on a very slow page with lots of html you may see flash for a couple of seconds).

The only way to allow flashblock to block in a sane manner would be to replace the actual Flash binary with our own binary clicker that only calls the original adobe flash binary after clicking to view.
Everything else is a hack.

Re:flashblock ftw!

[morgan_greywolf]

The only way to allow flashblock to block in a sane manner would be to replace the actual Flash binary with our own binary clicker that only calls the original adobe flash binary after clicking to view.
Everything else is a hack.

So? Get to it, man! C'mon! Time's-a-wastin'! Fire up that Emacs!

Re:flashblock ftw!

[RalphSleigh]

Are you sure? Firefox does not fetch the .swf file until you click the button (I just checked with firebug and wireshark), so unless the exploit can be trigged by the html object code, I would assume you are pretty safe.

Re:flashblock ftw!

[Hatta]

Or use NoScript. I don't know why anyone would use Flashblock when there's NoScript.

Re:flashblock ftw!

[LiquidCoooled]

Yes, I am sure.
You are right, and I pointed that out at first, it doesnt happen most of the time, but it can occur.

go read the source.
http://www.mozdev.org/source/browse/flashblock/source/content/flashblock/flashblock.xml?rev=1.34;content-type=text%2Fplain;sortby=date

Look for the settimeout values which indicate you want a callback event raising after a specified period.

The period is set to 0, but as with all callbacks, I believe it does not run instantly.
(This code used to fail if you just call the flashblockShowPlaceholder() function directly because the actual DOM is not completely initialized)

Most of the time the flash will be blocked instantly, but if other threaded operations are ongoing and the page load is not simple then the flash actually gets time to run.

(If its totally changed and is really secure I will be very pleasantly surprised, but from the looks of things it hasn't yet).

Re:flashblock ftw!

[Inda]

LiquidCoooled is right.

Try it on an old PC (450mhz in my case) with many applications running. I can often hear the sound from the Flash player advert or video before it is 'blocked'.

Re:flashblock ftw!

[Anonymous Coward]

NoScript does prevent Flash from running.

Re:flashblock ftw!

[LiquidCoooled]

Without checking I cannot be certain, but I would imagine that anything hooking onto the DOM event tree is too late.

It may be interesting to see if noscript suffers similar issues.

Maybe some enterprising young security guy could investigate (send reports to flashblock so they an make improvements if required).

Re:flashblock ftw!

[RalphSleigh]

Ok, fair enough.

I am suprised however there is no way to mess with the DOM before its rendered, but I guess this is a performance thing..

Re:Is this new?

[somersault]

That's what the aliens get for abducting Bill Gates and basing their Mothership's OS on values obtained while probing his anus..

Re:Big deal

[Viol8]

Many explits in cross platform systems can run anything if you shove the correct binary down the pipe to the exploit. Why is this news?

hang on...

[highwaytohell]

null pointers exploiting excited researchers? it all sounds a little goatse to me...

Re:hang on...

[4D6963]

null pointers exploiting excited researchers?

What else can you expect from people whose job is to find security holes, study them and, dare I say, "fill" them.

Re:boring?

[somersault]

This is more like a cat up a tree armed with a sniper rifle, picking off any emergency service personnel that get too close while his buddies rob a bank.

So... 0x8000000 is salt?

[CarpetShark]

You might need to dumb this down a shade for me, but from what I (think I) understand of it, it sounds like 0x8000000 is used as a kind of internal salt during bytecode compilation/execution for structure offsets so that the unchecked user code can't arbitrarily access structures?

If so... why would they do that? Why not simply ensure that offsets can't go above, say, 0xffff, and then make sure program code/data is well above that?

Re:So... 0x8000000 is salt?

[siride]

0x80000000 makes it negative in this case...I believe.

Re:So... 0x8000000 is salt?

[n0-0p]

It's not a salt, it's just an artifact of how the Flash VM operates. There's a year-old post on Dowd's blog with a much simpler example of the same class of vulnerability: http://taossa.com/index.php/2007/04/15/bored-games/

Basically, the vulnerability occurs when you can write to an arbitrary offset from NULL. This is probably a common enough mistake that no one has been looking for because NULL derefs are usually just a crash bug. What Dowd has shown is that with a little application knowledge, and control of the deref value, you can make this type of bug into a perfectly reliable exploit that is unaffected by application hardening like stack canaries and heap checking.

Why the java icon?

[LarsWestergren]

The paper specifically talks about the ActionScript virtual machine, i.e. the Flash player VM. There is nothing in there about Java. Why the Java icon? Why the Java tag?

When it comes a day after this flamebait article you have to start to wonder if the Slashdot editors are busy with some massive FUD campaign against Sun or if they are just really ignorant.

Re:Why the java icon?

[Roofus]

I was wondering the same thing with the Java tag. My thought is the editors are actually ignorant and biased.

Re:Why the java icon?

[ChunderDownunder]

Probably because they see JavaScript, bytecode and virtual machine all in the same sentence. Put two and two together and you end up with five.

Re:Why the java icon?

[baadger]

Java is JIT'd in a VM, this Flash exploit is essentially about busting through VM's. There is vague linkage here.

Re:Why the java icon?

[Ox0065]

obviously the byte code connection... ...and the lack of an actionscript icon.
I would have thought it warranted a good hard think & a review of peoples blind faith in the interpreter to save them from baddies. Don't you think people will start searching the Java interpreter for a similar problem?
I do take your point though, that perhaps .net might be a more rewarding field to dig in...

Re:Why the java icon?

[LarsWestergren]

Probably because they see JavaScript, bytecode and virtual machine all in the same sentence. Put two and two together and you end up with five.

Bah, I preferred my wild conspiracy theories. Anyway, if you needed another good reason to install NoScript... :)

Re:Why the java icon?

[GeoVizer]

Mod parent UP. This has nothing to do with Java, and in fact Java should be immune to this class of exploits.

Re:Why the java icon?

[LarsWestergren]

and in fact Java should be immune to this class of exploits.

Not guaranteed unfortunately... the Flash VM has a bytecode verifier and a security sandbox just like the JVM does, this exploit just managed to find a hole in the verifier. There might be similar vulnerabilites to be found in the JVM, .Net and other VMs.

Re:Why the java icon?

[JavaRob]

Probably because they see JavaScript, bytecode and virtual machine all in the same sentence. Put two and two together and you end up with five. Actually, if "JavaScript" had been in the summary, maybe something would have clicked (remember the years of yelling that JavaScript != Java?). But the summary only mentioned ActionScript....

Besides, the icon is initially selected by the submitter (though the editors can change it).. that means we have at least two people who had no idea what this article was about.

Re:fubar

[Anonymous Coward]

The NX bit doesn't get rid of the problem entirely, though. To use this example, it sounds like an exploit can be written pretty much entirely in ActionScript bytecode. Also, just because the stack is non-executable, what's to stop me from replacing the return address to point at, say, libc's system(), placing a nasty shell script on the stack?

Re:boring?

[ubernostrum]

Wow, an error in a program. This seems akin to ground-breaking front-page news: a cat stuck in a tree rescued by firemen.

Actually, it is a big deal, as you'd know if you'd read the article(s). But you're too lazy for that, so here's the short summary:

Lots of interesting (and important) security problems revolve around figuring out a way to take an error in a program, and turn it into a way to have that program execute arbitrary code of your choice. Traditionally, NULL pointer exceptions have not been fruitful ground for this because, well, a NULL pointer is NULL -- there's nothing on the other end of the pointer for the unsuspecting program to read or execute, so it simply crashes. And merely crashing the program isn't really all that interesting, since at best it lets you execute a denial-of-service. But this guy (Dowd) found what would have been a run-of-the-mill NULL pointer exception in Flash and parlayed it into full-scale arbitrary code execution through a series of fairly impressive tricks. You really should go read Ptacek's summary, because it has all the gory details and will, if nothing else, make you realize what an amazing hack this is.

Why Java?

[vvsiz]

How on Earth this is Java related and tagged with 'java' keyword?

Re:Why Java?

[vvsiz]

But again, this has *nothing* to with Java. Zero. :) Well, except for the completely unrelated fact that Javascript has 'java' in its name. JavaScript and Java are not related.

Re:Why Java?

[fuego451]

Indeed! I was merely pointing out where the poster got 'java'. I should have been clearer. Even with my limited knowledge, I understand that javascript only shares some C syntax and naming conventions with java.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:fubar

[Anonymous Coward]

You don't have to come across this exploit for your browser to crash in Vista, normal browsing does that just fine.

Crap factor 11 Captain?

[Nomen Publicus]

Crappy programming allows successful hacking?

Wake me when something new happens.

Seriously, who in this day and age doesn't check the return codes of library routines when writing software that will be deployed on millions of computers?

Re:Crap factor 11 Captain?

[RenderSeven]

"Who in this day and age?" Well, a lot of people, and not just stupid ones.

OK, checking for malloc status is pretty much mandatory since it reflects a dynamic resource that is expected to change over time. However, the extraordinarily large percentage of library calls one makes can be expected to be consistent, and the checking takes time, and handling a failed code sanely is usually more work than a module's primary function.

Code that I consider 'good' uses asserts or other compile-time constructs to check all library returns, and after the code is run through fairly comprehensive testing, the checks and asserts are compiled out for the deliverable version. This is extremely common for OS, driver, and application code. I think calling it 'crappy' is a gross oversimplification.

What you seem to suggest is that all code should be written with the assumption and mindset that every function you call is malicious, and every function that calls yours is malicious. From an anti-hacking point of view thats all dandy. From a speed and code size point of view, its impractical. Like everything else coders need to strike a balance by understanding where the risks and vulnerabilities are, and thats not as simple as you make it sound.

Add to that the re-use of common code, where vulnerabilities change from implementation to implementation. Say I write code for a small embedded application, use asserts to test that crap out of it, and deliver it. Later the company takes my code and uses it somewhere else without really understanding the assumptions made when it was written, and it turns out there is an exploit in the new use case. I dont call that 'crappy'. It may be bad, it may be short-sighted, but laying the blame squarely on the original coder is pretty naive. No offense, but I hope you never write any code for me.

If your pointer is NULL

[superbrose]

...you'll need a pointer first.

Re:If your pointer is NULL

[smittyoneeach]

Not Usable 'Less Lifted?

Re:Big deal

[cheater512]

No, it cant mess around with the browser.

It can mess around with Flash and execute arbitrary code with either browser but not mess with the browser its self.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Could someone please...

[capn_buzzcut]

explain this event in terms that a person with a sex life not involving the Internet could understand?

Re:Could someone please...

[gasmasher]

Ha, I see what you have done. You made a joke based on the stereotype that people who understand computers are incapable of finding a mate for sexual intercourse. Very funny!

Re:Could someone please...

[ultranova]

explain this event in terms that a person with a sex life not involving the Internet could understand?

"If you let your computer fuck with shady websites, it's condom-equivalent might burst, in which case it'll get infected, propably with something nasty. This is because the manufacturer - Adobe - of its virtual Viagra-equivalent - called Flash - made a stupid error in the manufacturing process.

It was suggested on a net forum Slashdot that the underlaying cause of the problem is in the so-called C/C++ manufacturing equipment used, which is well known to be almost impossible to use correctly, and that the whole episode could had been avoided by using another, more advanced process which automates the difficult parts so the user can't screw them up. This immediately drew a chorus of protests from people defending C/C++ and opposing the idea of automation."

Re:Could someone please...

[ruiner13]

explain this event in terms that a person with a sex life not involving the Internet could understand? Ok, I'll try. Say you're about to have sex with a woman. You don't have any condoms, so you ask her for one. She doesn't have any, but doesn't tell you that, and instead gives you saran wrap and a rubber band. You don't check to see if what you got was what you asked for, and go about having sex. A few weeks later, you get a call that she is pregnant. She now has control over your life.

Sorry, that's the best I can do after being woken up at 5:30AM by a stupid earthquake :)

Re:Could someone please...

[mr_mischief]

Don't be silly. Humans are quite inflatable. Past a certain point, though, I imagine it gets quite uncomfortable.

Re:Could someone please...

[mr_mischief]

C was and is a systems language. Large applications aimed at unskilled end-users with lots of graphics and features were not really part of its design criteria. It's quite possible for a skilled C programmer to use C correctly in the scope and problem domain for which it was designed.

Problems like this stem from people using a language well-suited to OS kernels, system libraries, and bit-twiddling to do things better suited to other languages. The reasons for that involve installed base of C/C++, poor solutions for distributing code without massive runtimes for other languages, the difficulty of mating programs in some other languages to the libraries provided by the OSes for C, the speed sacrifices many other languages make, and the need to run in tiny spaces on some of the targets of programs like Flash.

Certain other languages fit the application domain of Flash much better, but for various reasons Macromedia chose C. Despite being a poor fit for the domain, it was what they felt was the best fit for their needs overall. That's not high praise for C, but a problem for the implementations, performance characteristics, and supporting environments for languages which otherwise would have been better suite.

Re:Could someone please...

[ralphdaugherty]

explain this event in terms that a person with a sex life not involving the Internet could understand?

      does blow up dolls count?

Pedantic

[noidentity]

NULL is the name of a macro in C. Null is the name of the value which it (and the integral constant 0) put into a pointer; it's a regular noun with no capital letters (except when at the beginning of a sentence, of course).

Re:Big deal

[Anonymous Coward]

Because it can probably be made to work cross-version, cross-platform and cross-architecture?

Because everyone has Flash installed?

Because it opens up a whole class of common bugs previously thought to be unexploitable?

Because the way he does it is nothing short of godlike?

This is HUGE.

Obligatory Bad Pun

[Prototerm]

Null is a four letter void.

NoScript in Firefox

[A Pressbutton]

Plugins Tab

Switch on Forbid Macromedia Flash

Switch on Apply these restrictions to trusted sites too

Click OK.

Say goodbye to YouTube :)

Re:fubar

[orasio]

FYI: you can type about:plugins in the address bar, when you need to know anything about plugins.
If you want to know something about the config, you type about:config and get to the super duper advanced settings page.

Re:fubar

[morgan_greywolf]

The NX bit doesn't get rid of the problem entirely, though. To use this example, it sounds like an exploit can be written pretty much entirely in ActionScript bytecode. Also, just because the stack is non-executable, what's to stop me from replacing the return address to point at, say, libc's system(), placing a nasty shell script on the stack?

This assumes, of course, that you know the entry point of libc's system(). Since glibc is typically a dynamically-linked ELF .so these days on Linux, this means that you need to know the architecture on which your target is running, the specific version of glibc in use, etc.

While you can determine this easily for any given architecture/Linux distro pair, determining what particular distro and architecture are present from remote is problematic at best.

Furthermore, if I'm not mistaken, there are certain SELinux rules you can use to prevent shell scripts from doing nasty things.

Re:fubar

[Hal_Porter]

True, but if ASLR was enabled system() would be at a different address each boot.

But I don't think any of these things are foolproof on their own. Even the combination of them can be exploited if you have the right sort of bad code. But ASLR+Running processes with low privilege levels+stack canaries+NX does stop a lot of exploits.

In this case if ASLR had been enabled in the flash binary it would not have been possible to execute arbitrary code.

Re:fubar

[Anonymous Coward]

If you find that it is possible that a wheel can fall off your car, do you fix the problem because:

a) if the wheel falls off at just the right time, your car can swerve into oncoming traffic and kill an entire bus full of precious children,

or

b) wheels coming off cars are a generally bad thing.

?

Rephrasing the question: do we fix a NULL pointer problems because

1) some clever guy with time to waste might be able to figure out how to convert the problem into the erroneous detonation of a nuclear warhead,

or,

2) because it is just an easy-to-fix stupid bug, and bugs are just bad in general?

My assessment of this situation is that far too much analysis was undertaken. Rather than piecing together some careful exploit, this guy could have spent the time looking for other bugs in the code instead. NULL pointer dereferences are among the easiest bugs to find and fix. Report it, fix it, and move on. Filling the net with manifest useless fear while you try and prove your cleverness accomplishes ... what?

Re:Big deal

[Simon Brooke]

I don't think I'll be updating adobe on my linux box just yet. sudo apt-get update; sudo apt-get upgrade

solves the problems on Ubuntu boxes as of this moment, so someone at Ubuntu is paying attention. Don't know about Debian, because I don't run Flash on any of my Debian machines.

Re:fubar

[X0563511]

about:plugins is what you want. Why this isn't linked or otherwise brought to light, I don't know. I discovered this by trial/error and/or boredom.

On mine, I see this:

Shockwave Flash
        File name: NPSWF32.dll
        Shockwave Flash 9.0 r47

Re:boring?

[SQLGuru]

It can't be the best analogy of the day.......there were no cars mentioned in it.

Layne

Re:fubar

[Hal_Porter]

You're aware this site is News for Nerds, right? If this sort of thing is boring to you, maybe you're on the wrong site.

Dilbert became Flash-only today - coincidence?

[Shirotae]

Is it just a coincidence that the daily Dilbert cartoon has gone Flash-only today?

I have never liked Flash, mainly because it was used as a distracting and irritating advertisement medium, but also because of the arrogant assumption that the Flash page author should be in control of what my machine does. I don't want my browsing experience reduced to some funereal pace at the whim of a marketing drone who thinks his tedious animation should occupy my time.

I was reconsidering my decision to give up reading Dilbert because of the switch to Flash, but now that I have read about this exploit I think I will stick to my No-Flash policy.

Yes I know, this exploit has been fixed in some version of Flash to which I may have upgraded but what about the next one?

Re:Dilbert became Flash-only today - coincidence?

[LurkerXXX]

I was just going to comment on that. Wild coincidence. And a bit of irony.

I didn't read todays cartoon either because of the flash requirement. Looks like I won't be reading dilbert anymore.

Re:Dilbert became Flash-only today - coincidence?

[JavaRob]

I was reconsidering my decision to give up reading Dilbert because of the switch to Flash, but now that I have read about this exploit I think I will stick to my No-Flash policy. Just don't read it at dilbert.com.
Try this instead.

Re:Big deal

[hesaigo999ca]

this post of yours shows your lack of understanding about code execution,
how many stories have you read abou IE running code it shouldn't with admin privs.
installing active x?
maybe not on vista, but i don't know vista well enough to say anything about it.
I heard vista was made to stop your browser from doing this, however firefox
installed side by side IE opens up yet another vulnerability that I think might work on vista...
if my memory serves correctly.

Re:boring?

[pardillo]

I've read the article (the topic is always interesting, and Ptacek is well-known in the security world). I must have missed something, because I still see the problem as a combination of really lousy programming* from the Flash guys, plus a bunch of cute hacks from Dowd to overcome the exploit limitations.
From the article:
"It then uses that pointer [the NULL pointer] with an offset controlled by the attacker."
Well, what's left to say? If you allow extraneous information to set the offset of an address in memory, you're dead meat, period.
Best,
*I definitely agree with Ptacek's comment on how malloc() should always be checked. I still think that the default one should remain unsafe (too much old code may depend on this), and instead libraries should provide a safe_malloc() that punts on failure.

Non-issue

[gr8_phk]

One thing that is overlooked. They include the arbitrary code in the flash file and then use this exploit to run it. If you've got no-execute enabled for data and stack, this will crash and not do anything.

Reason for the Excitement

[scruffy]

Anything involving misbehaving NULLs excites old LISP programmers.

Re:Big deal

[n0-0p]

It's news because it's a general method for code execution from a common class of NULL pointer dereferences. He turned something that most people consider a crash bug into a code execution bug. Here's a simpler example from Dowd's blog: http://taossa.com/index.php/2007/04/15/bored-games/

The other reason why it's news is that his method for exploiting Flash in this case is technically brilliant. I can understand if you don't appreciate it, but any security people out there are just overwhelmed.

Re:boring?

[ari_j]

I think that a better write-up may have made that more clear. The one that was actually posted on the Slashdot front page is pretty weak.

What's ironic..

[encoderer]

What's ironic is that this exploit DOESN'T crash the browser! That's the whole ever-fuckin point.

A browser crash is what's SUPPOSED to happen here to prevent the exploit from deploying its payload. I mean, in this case, a crash is the DESIRED behavior. An uncaught exception should be thrown.

So... just walk with me here... maybe Windows isn't just unreliable and unstable. MAYBE it's the most secure application stack ever devised. ...oh, hell...nevermind

Re:What's ironic..

[slyn]

An application crashing is not a bug, its a feature!

Where have I heard that before...

Spoiler: pointer to this unbelievable article

[i-neo]

Segmentation Fault (core dumped)

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:boring?

[Mr. Slippery]

Traditionally, NULL pointer exceptions have not been fruitful ground for this because, well, a NULL pointer is NULL -- there's nothing on the other end of the pointer for the unsuspecting program to read or execute

Anyone who assumes this has never done cross-platform work. You don't know what's on the other end of NULL; you're only guaranteed that you can tell a NULL pointer from any other other pointer.

I've always worked under the assumption that my code might someday be ported to an architecture where NULL pointed to the routines involving the launch of nuclear missiles...

This is not the first NULL pointer exploit, not by a long shot. Not to say it's not very clever and all, but the "OMG! Not checking pointers for NULL is dangerous?!?! Who knew?!" reaction is frightening. Anyone who doesn't know that checking pointers for NULL is necessary, should please delete any C or C++ compilers on their machine.

Re:fubar

[crymeph0]

Actually the researcher specifically crafted his exploit demo so it wouldn't crash the browser. Maybe if I intentionally get infected, Vista won't suck as much!

Re:boring?

[kitzkar]

If this isn't news for nerds, then I don't know what is.

Re:Big deal

[Viol8]

The flash interepreter is loaded as a dynamic library by the browser. Ergo , if it has control of the flash interpreter memory space it has control of the whole process memory space which includes the browser. On unix anyway, can't speak for windows.

Try again

[Anonymous Coward]

Attitudes like yours are the reason people keep getting owned. There tons of ways to get around NX. You could do the pwn to own thing and use something like Java to allocate an executable range. Or you can use a return to libc style attack. There's so much crap running in a browser that you have nothing but options.

Obligatory

[killmenow]

The original article already has Russian trackbacks on it.

In Soviet Russia, trackback adds article to you.

Re:Help me out here...

[Flaming_cows]

Yes, it's easily patchable once you realize it's there, and yes, it should have been easy to check for. This isn't as revolutionary as the summary might suggest, but it is still interesting. The way Dowd jumps through a bunch of hoops to achieve the exploit is interesting to learn from, in the same way a perfect shot in pool or pitching a no-hitter might be to a sports fan. Dowd showed an amazing amount of technical skill by putting together all the pieces, and people are reacting to that more than the specific bug(s) that allowed it, though those are interesting as well in some ways.

Re:fubar

[RKThoadan]

Well, until now it was generally consdiered an un-exploitable error. Now it's not. That changes things.

Re:fubar

[naasking]

Mind you, if Address Space Layout Randomisation was turned on in the Flash executable on Vista, exploiting this hole would most likely (255 times out of 256) lead to a browser crash rather than arbitrary code execution

Are you sure about that? My skimming gave me the impression that all addressing used in this exploit was relative, which means address space randomization wouldn't have helped. Randomization just randomly places dynamically linked libraries, the start of the heap, and the stack, but that doesn't affect exploits on blobs of memory addressed using a relative offset.

Re:fubar

[Hal_Porter]

The NULL pointer dereferencing uses an absolute address, well a relative one from 0 which is the same thing. E.g. it does this

http://www.matasano.com/log/1032/this-new-vulnerability-dowds-inhuman-flash-exploit/

Not this time. Flash forgets to check that allocation failed, a ludicrously common error. It then uses that pointer with an offset controlled by the attacker. NULL isn't valid. NULL plus 1024 isnâ(TM)t valid. But NULL + 0x8f71ba90 is, as is NULL + N for any N that addresses valid memory.

To this address, controlled by attackers via wild offset, Flash writes a value that is also controlled by the attacker. This is the write32 pattern: a vulnerability that gives the attacker the means to set any one value in memory to a value of their choosing. Game over.

Except not quite.

The exploit doesn't actually get to offset an arbitrary number of bytes from 0. A complicated set of conditions constrains the address it writes to and the value it gives it.

The the actual write occurs via a structure offset. Flash is hardcoded to translate your offset into another number. Working offsets, as it turns out, will be greater than 0x80000000, and will be evenly divisible by 12 after 4 is added to them. Note: I thought I was hardcore when I wrote shellcode with no lowercase letters for the IMAP vulnerability in the â(TM)90s

....
Two fun details.

First, even though IE and Firefox use different Flash builds, the addressing inside them is compatible. The exploit works in both places.

Second, Flash isn't compiled with ASLR. So the attack works on Vista.

Mass casualty. Go Flash!

Re:fubar

[0xygen]

I have not checked, however I think the chances are that Flash would link to one or more calls you could use as a stepping stone to get the calls you need.

For example, the attacker being able to take the function addresses from the fixed up imports somewhere within the unrelocated Flash binary, rather than trying to call the function directly.

Read the actual paper

[Animats]

Cute. Read the actual paper from IBM, not the blogodreck. The same attack works on IE and Firefox, on XP and Vista. An attack for Firefox on Linux is probably possible.

This is easy to fix; it's a one line bug in Flash. But it will take years to replace all the bad versions of Flash out there.

Re:fubar

[0xygen]

We can only hope that with an exploit against a target with such an enormous installed base, opening up multiple platforms to remote code execution will lead to enough press that other vendors realise the steps they need to take sooner rather than later.

Let's hope more vendors than just Adobe learn their lessons from this one!

Anyone know what the right thing to run browsers with reduced privelegs on Linux actually is? Is this a feature of SELinux?

Re:He's stunned all right...

[ClamIAm]

What kind of title is that?

Swedish?

This is NOT JAVA

[coder111]

This is a Flash plugin problem, not java problem.

Why on earth is it under Java section and with Java tag?

--Coder

Re:This is NOT JAVA

[JavaRob]

Well, but, uh, Sun is probably behind it somehow, those evil bastards. It's something to do with their hatred of open source.

Didn't you get the memo?

Heh.

That's new?

[12357bd]

A program (flash player) allows to write to an uncheked addres, that's all. Add a simple check, and the problem is gone. It's the end of the world as we know-it?

Re:fubar

[Gr8Apes]

but with Firefox's noscript and flashblock plugins, how likely is it that this is a problem? Not very.

The real crux of the problem...

[cwills]

Actually... if you want to go back one step further, one of the major reasons why these types of exploits exist is because of the default behavior of many of the C library (and the underlying operating system API).

In a "different" world, the default behavior for a failed system API call would cause the operating system to terminate the application. To override this behavior, the application author would have to explicitly tell the system API that it would handle the error condition.

The current method rewards the programmer for not adding the additional required code to handle an error. The reward is a simple, runnable, program, but one that contains a hidden time bomb just waiting for the right error condition.

The exception (catch/try) model is another way to handle these types of errors, if the system APIs would throw the exceptions.

The problem however that the cat is out of the bag so to speak. The major systems out there (Windows, Unix, Linux) have been built with a basic assumption that coders are performing due diligence by programming defensively.

Re:Slashdot's slow, Dowd's a genius.

[JavaRob]

Slashdot articles are all submitted by users.
So...

Re:fubar

[mr_mischief]

The fact that it's a bug and needs to be fixed hasn't changed. Its priority come debugging time just jumped up quite a bit because it went from a stability issue to a security issue.

Debugging is generally handled in a triage fashion. The first bugs to fix are easily exploitable remote exploits that allow arbitrary code execution with elevated privileges. Then come those that allow easy remote exploitation and arbitrary code execution at the user's restricted level. It goes on like that all the way down to a bug equivalent to "sometimes on platform X the last character of output sometimes is an extra newline that gets appended which is unnecessary".

If you have the time to make sure every piece of software you write is entirely and certifiably bug free, then that's great. Somehow, though, I imagine maintenance programming for the rest of us will probably still be prioritized based on severity.

Re:boring?

[Sloppy]

But isn't it just a bug in Flash? Fix that bug, and this whole story goes away. What am I not getting? I mean, I get how the installed base for this bug happens to be large, but it's not like this really opened a bigger can of worms than that, is it? Failed mallocs are still something that will be rarely exploitable.

Re:Big deal

[Viol8]

Didn't look that brilliant to me. A clever hack but not genius. As for security people being overwhelmed? Oh please.

(And yes I did RTFA and the relevant bits of the paper.)

Re: are executions necessary?

[Have Brain Will Rent]

Most of the patches I see popping up in Ubuntu's update notifier seem to involve buffer overflows. Now there is this exploit because someone didn't check a pointer (failed malloc()/new/etc?).

When I taught CS, back when dinosaurs ruled the earth, I would have given a homework assignment with anything like that a D or an F.

I mean WTF, fast forward a few eons and people are still writing code like this??? What do we have to do - shoot them???

A programmer not checking for a null pointer return or a buffer overflow is the equivalent of... geez, I don't know... a surgeon forgetting to wash his hands before operating?

Re:Big deal

[Mr Z]

One hacked ad server and you've pwn3d thousands upon thousands of users. And they'd be none the wiser.

Umm, So what?

[JSBiff]

First, I don't think anyone seriously considers that Silverlight is *probably* more secure than flash - just people have had less time to analyze it for exploits. Though, it is possible, I suppose, that it might be more secure.

Second, *even* if we allowed the hypothesis, for argument's sake, that Microsoft is acting to promote public awareness of this problem to promote it's own agenda, so what? Either this bug/exploit exists, or it doesn't exist, and it doesn't make it any more true or false just because Microsoft happens to be helping the problem to get attention (not that I am agreeing that is the case). If Microsoft *is* publicizing this, great - the more people that are aware of this, the more that will, hopefully, upgrade to a patched version of Flash and avoid getting Pwned.

Re:Big deal

[adavies42]

Wise men have commented that difference between a bug and a vulnerability lies only in the skill of the exploiter.

Re:Big deal

[krunk7]

E=mc^2

Pretty simple eh? I mean overwhelmingly simple. Sometimes brilliance isn't in the complexity of the pudding, but the fact that no one had thought or even begun to think of the recipe before.

Re:fubar

[Tweenk]

I believe at least some versions of Linux have adress space randomization turned on by default, so it's generally not possible to know where system() is beforehand.

Re: are executions necessary?

[TapeCutter]

"A programmer not checking for a null pointer return or a buffer overflow is the equivalent of... geez, I don't know... a surgeon forgetting to wash his hands before operating?"

Sorry but that conjures up a picture of Dilbert's PHB: "I'm giving you an under-performer rating on your last project Dilbert. I shouldn't have to hire someone to test your work.".

The biggest overflow culprit is probably strcpy() or a similar library function. Most proprietary and open source application code I have seen over the last couple of decades do not explicitly check buffer lengths before calling strcpy, etc. What most applications do (if anything) is focus on input validation and then blindly throw the validated data at library calls or lower level parts of the application code. What you were asking the students to do is act like every bit of code is paranoid interface or library code but the vast bulk of code out there is not written that way, nor should it be.

Writing and to a lesser extent using library code is always a trade off between saftey, speed, and the number of hours in a day. This is why writing a general purpose library/interface that adds something usefull to the art or science is difficult for vetrans let alone students.

I also taught programming to 1st and 2nd year CS students in the early 90's, in my experience many students found it difficult to fully grasp the concept of pointers even after two years with several different explainations from different presenters using different programming languages. Asking them to write bullet proof (sloth like) code is a waste of time. Sure, make them aware of defensive programing techniques, work it into assignments and award points it. However in an educational setting, well commeted and readable code that makes a decent attempt at the assigned problem and it's constraints is far more important than passing the keyboard bashing test and grades should reflect that.

Re:boring?

[starling]

Yeah, that's what I was trying to say.

Re:Big deal

[tyrione]

It can run anything. If you read the paper, it explains that once you desynchronize the interpreter from the validator, you are running x86 instructions. One might have to tailor the exploit to work differently on Linux/Unix than on Windows due to the different executable addressing schemes, but once that is determined you are in business. And here I was hoping they [Adobe] had managed to get anywhere on AMD64 Linux version for Flash. Perhaps this can be used as an excuse to update this on all platforms, current and upcoming?

Re:Big deal

[icebike]

But all it takes to prevent this is fixing the original flash bug of marching on even in the face of a malloc failure.

For pete sake people, get a grip.

Flash people can learn to code defensively, like everybody else in the industry.

Until they do, we can all de-install flash and live in a world were every web page actually does not assault your sensibilities with annoying ads.

The value of flash is highly over-rated, and now it is revealed that the code base is as well.

Flash delivers garbage to my screen.

Not surprisingly, it turns out that its made of garbage code.

Gee, what a revelation.

Re:Big deal

[demallien2]

Yup, I'd have to agree with you. Whilst Mark's work here is neat, it's hardly earth-shattering. It's a pretty standard reverse engineering of a VM to understand it's internals, discovering an absolutely pathetic memory protection scheme, and writing what is finally a relatively simple exploit. Generally speaking, security professionals are more likely to b bemused by the lack of a secure memory model for the ActionScript VM. Implementing the VM stack on the CPU's stack? Now there's an idiot security breach just waiting to happen. I imagine they did it for performance reasons, but good grief, Adobe has only themselves to blame if ever anybody uses this exploit for evil.

Re:boring?

[ralphdaugherty]

I think that a better write-up may have made that more clear. The one that was actually posted on the Slashdot front page is pretty weak.

      Just click on TFA. It explains it well.

  rd

Re:fubar

[Corwn of Amber]

Well, unless your straming pr0n has viruses in it, yeah, you're 100% safe. Malware only happens in advertisements these days.

Re: are executions necessary?

[Have Brain Will Rent]

Sorry but you are not part of the solution, you are part of the problem.

Having code testers is no excuse for the original programmer being sloppy.

What most applications do (if anything) is focus on input validation and then blindly throw the validated data at library calls or lower level parts of the application code.

Which you appear to endorse. And which is also the cause of the many buffer overflow bugs, exploits and fixes thereof.

What you were asking the students to do is...

What I was asking the students, and any programmer, to do is this: do not copy a block of memory to another block of memory unless you know the destination block is large enough to contain the data you are copying.

Anyone who does not get why that is necessary should not be allowed near a computer.

Asking them to write bullet proof (sloth like) code is a waste of time.

Claiming that code that doesn't make unsustainable assumptions is "sloth like" is just a straw man, and a rather tired one at that. It doesn't deserve to be taken seriously, and so I won't.

"well commeted and readable code that makes a decent attempt at the assigned problem and it's constraints is far more important than passing..."

Ummmm no. There is your problem right there - looking pretty is not more important than working properly.

and grades should reflect that.

What makes you think their grades didn't reflect "commenting and readable" as well as correctness? Sorry but in software, just as in horseshoes, "close" doesn't count. And one programmer spending one extra hour to make sure that 1,000 users don't each spend an hour dealing with a bug is a good investment by any sane standard.

"two years with several different explanations from different presenters using different programming languages

If after all that students didn't fully understand pointers then I suspect there is a more serious problem at the institution. The only thing necessary to get students to understand pointers is to teach them assembler for an architecture with indirect addressing, i.e. almost any modern cpu. Period. End of story.

Here's an exercise for you:

Repeat

Say "Do not copy a block of memory to another block of memory unless
you know the destination block is large enough to contain the data you are copying."

Until understood;

Re: are executions necessary?

[TapeCutter]

To emphasis my point you orinally wrote "A programmer not checking for a null pointer return or a buffer overflow is the equivalent of... geez, I don't know... a surgeon forgetting to wash his hands before operating?" To which I basically relpied that checking usually only needs to occur when talking input from outside your app and that a common and trivial mistake made by proffesionals is no justification for failing a student.

Not that someone like you would have made a mistike in your original statement but now you are telling me it means something different to what it actually says (ie: it now means "Do not copy a block of memory to another block of memory unless you know the destination block is large enough to contain the data you are copying.")

"Having code testers is no excuse for the original programmer being sloppy."

Never said it was, but in the real world as compared to your ivory tower only an idiot trusts a team of programmers to get everything right the first time. Take a look at the bug list for any major application, crappy apps don't have such lists (Hint: Absense of a bug list does not imply the programmer 'got it right').

Now here's a looping exercise for you:

Say: "In the real world people are expected to make mistakes despite their best efforts, teachers are not employed to act as a lint program." - until it bores through your ridgid ideology and the contorted logic you use to keep it alive.