×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

NULL Pointer Exploit Excites Researchers

Soulskill posted about 6 years ago | from the ruh-roh-shaggy dept.

Java 327

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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

327 comments

fubar (0)

Anonymous Coward | about 6 years ago | (#23115200)

Memory corruption vulnerabilities can easily be exploited using application-specific attacks, ActionScript Virtual Machine is just the current opening.

Re:fubar (5, Interesting)

Hal_Porter (817932) | about 6 years ago | (#23115334)

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 [msdn.com]"

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 [adobe.com]

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:fubar (3, Insightful)

Anonymous Coward | about 6 years ago | (#23115494)

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:fubar (2, Insightful)

morgan_greywolf (835522) | about 6 years ago | (#23115904)

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 (1)

Hal_Porter (817932) | about 6 years ago | (#23115978)

True, but if ASLR [wikipedia.org] 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 [wikipedia.org]+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 (4, Funny)

Anonymous Coward | about 6 years ago | (#23115530)

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

Re:fubar (4, Informative)

liquidpele (663430) | about 6 years ago | (#23115590)

Since I couldn't find where to look in the firefox menus, you can find out your current version by visiting this page: What is my version of flash? [adobe.com]

Re:fubar (4, Informative)

orasio (188021) | about 6 years ago | (#23115852)

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 (-1)

NotZed (19455) | about 6 years ago | (#23115648)

Its not a buffer overflow against a badly written C app.

It's just another exploit in yet another badly written C app.

Big Fucking Deal.

Aha! (4, Funny)

Rik Sweeney (471717) | about 6 years ago | (#23115206)

So you CAN get something from nothing!

He's stunned all right... (-1)

Anonymous Coward | about 6 years ago | (#23115218)

Nathan McFeters at ZDNet is 'stunned by the technical details.'

So stunned, he can't even spell "prove." From his extremely lengthy post title:
Mark Dowd's null pointer dereference exploit and advanced Flash ActionScript techiques proove definitively: Aliens Do Exist!

What kind of title is that — even if you overlook the spelling error?

The crux of the exploit: (5, Informative)

Ethanol-fueled (1125189) | about 6 years ago | (#23115222)

"...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: (5, Funny)

slapys (993739) | about 6 years ago | (#23115248)

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

Re:The crux of the exploit: (1)

Ethanol-fueled (1125189) | about 6 years ago | (#23115256)

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 :)

Big deal (0)

Viol8 (599362) | about 6 years ago | (#23115274)

"Flash builds, the addressing inside them is compatible. The exploit works in both places."

So it can mess around with the browser. Unless it can successfully exploit system specific API calls as opposed to browser APIs (you know , stuff like fork(), rmdir() etc etc) then its only ever going to be platform specific. And I think we can guess which one that'll be. I don't think I'll be updating adobe on my linux box just yet.

Re:Big deal (5, Informative)

Trouvist (958280) | about 6 years ago | (#23115336)

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.

Re:Big deal (1)

Viol8 (599362) | about 6 years ago | (#23115410)

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?

Re:Big deal (5, Insightful)

Anonymous Coward | about 6 years ago | (#23115778)

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.

Re:Big deal (0)

Anonymous Coward | about 6 years ago | (#23115792)

Read the bloody paper instead of asking stupid questions. This is a very advanced attack and you are just pooh-poohing it.

Most exploits are nothing more complicated than pushing code down an open hole, so to speak. This exploit is like designing a puzzle and then letting the program assemble it.

The dude that figured this out deserves a Nobel Prize in Awesome!

Re:Big deal (1)

cheater512 (783349) | about 6 years ago | (#23115556)

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.

So... 0x8000000 is salt? (1)

CarpetShark (865376) | about 6 years ago | (#23115436)

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?

You just plagiarized another article (0, Troll)

Anonymous Coward | about 6 years ago | (#23115444)

That's all

Re:The crux of the exploit: (0)

Anonymous Coward | about 6 years ago | (#23115540)

thanks for the excerpt, but next time could you add your comments in brackets or, better, close the quotation and reopen it after your comment. thanks.

Re:The crux of the exploit: (0, Troll)

master_p (608214) | about 6 years ago | (#23115586)

Thanks a lot.

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

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

Re:The crux of the exploit: (3, Insightful)

jo42 (227475) | about 6 years ago | (#23115620)

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: (4, Insightful)

hey! (33014) | about 6 years ago | (#23115782)

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

Re:The crux of the exploit: (2, Informative)

Anonymous Coward | about 6 years ago | (#23115808)

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: (2, Informative)

martinmcc (214402) | about 6 years ago | (#23115658)

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: (0)

Anonymous Coward | about 6 years ago | (#23115672)

Let's ignore the fact that you said C and C++ shouldn't exist, since other commenters have already addressed this. In C++, operator new throws std::bad_alloc on failure. Granted you can still use malloc and similar-style functions...

Re:The crux of the exploit: (2, Informative)

Rogerborg (306625) | about 6 years ago | (#23115716)

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: (4, Insightful)

pla (258480) | about 6 years ago | (#23115738)

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: (1, Insightful)

Anonymous Coward | about 6 years ago | (#23115798)

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: (2, Insightful)

spir0 (319821) | about 6 years ago | (#23115926)

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: (1)

Stellian (673475) | about 6 years ago | (#23115696)

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.

Binary blobs (4, Insightful)

should_be_linear (779431) | about 6 years ago | (#23115228)

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 (4, Informative)

CRCulver (715279) | about 6 years ago | (#23115268)

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 (2, Interesting)

atlastiamborn (1252206) | about 6 years ago | (#23115950)

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 (3, Informative)

vux984 (928602) | about 6 years ago | (#23115600)

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 (1)

AvitarX (172628) | about 6 years ago | (#23115784)

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.

Oblig (5, Funny)

Anonymous Coward | about 6 years ago | (#23115232)

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

Cool exploit so why am I yawning? (0)

Anonymous Coward | about 6 years ago | (#23115236)

The exploit is cool as hell from any perspective. As for the flash VM with it's inconsistencies between the bytecode verifier and interpreter -- what the fuck is that about?

Web executables (flash, java, activex, silverlight) are a bad idea, we've all known this since the beginning. If the security industry didn't place self-interest above security, they'd have shot these dancing pigs long ago.

Cross platform? I don't think so. (1)

Viol8 (599362) | about 6 years ago | (#23115266)

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. (3, Informative)

lisaparratt (752068) | about 6 years ago | (#23115332)

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. (3, Interesting)

Alioth (221270) | about 6 years ago | (#23115338)

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. (0)

Anonymous Coward | about 6 years ago | (#23115344)

The possibility exists to land shellcode on any platform with flash installed, flash is cross platform and so is the vuln. Being pedantic is fine, deliberately misunderstanding the writeup so you can make a snarky comment and sit back willowing in smug superiority is generally not ok.

HTH.

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

Viol8 (599362) | about 6 years ago | (#23115402)

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. (1)

bcmm (768152) | about 6 years ago | (#23115370)

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. (3, Interesting)

Anonymous Coward | about 6 years ago | (#23115392)

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?

Always check your return values! (3, Informative)

Anonymous Coward | about 6 years ago | (#23115288)

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! (1)

somersault (912633) | about 6 years ago | (#23115420)

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! (4, Insightful)

Tony Hoyle (11698) | about 6 years ago | (#23115592)

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.

boring? (0, Flamebait)

vikstar (615372) | about 6 years ago | (#23115298)

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

not boring (1, Informative)

Anonymous Coward | about 6 years ago | (#23115340)

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:boring? (4, Informative)

starling (26204) | about 6 years ago | (#23115358)

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.

Re:boring? (5, Funny)

somersault (912633) | about 6 years ago | (#23115434)

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.

Re:boring? (0)

Anonymous Coward | about 6 years ago | (#23115822)

I wish I could mod you +1, best analogy of the day.

Re:boring? (0)

Anonymous Coward | about 6 years ago | (#23115906)

Ah, so that's where this [photobucket.com] picture came from.

Re:boring? (5, Insightful)

ubernostrum (219442) | about 6 years ago | (#23115510)

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.

Re:boring? (-1, Troll)

Anonymous Coward | about 6 years ago | (#23115656)

you'd know if you'd read the article(s). But you're too lazy for that

Wow, rush to negative judgement much? Maybe the person just didn't have time because he/she was helping feed three kids. Maybe the person's 85 and gets tired eyes.

But no, you saw right to the heart of the matter, didn'tcha?

Have a nice day.

Re:boring? (0)

Anonymous Coward | about 6 years ago | (#23115850)

Yet he had the time and gumption to comment on the headline, didn't he?

hmm. (1)

apodyopsis (1048476) | about 6 years ago | (#23115366)

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. (2, Insightful)

keysersoze_sec (1229038) | about 6 years ago | (#23115506)

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. (2, Insightful)

JasterBobaMereel (1102861) | about 6 years ago | (#23115924)

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. (1)

ubernostrum (219442) | about 6 years ago | (#23115528)

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. (0)

Anonymous Coward | about 6 years ago | (#23115712)

From page 2 of TFA (page one is the title page):

"Although this document deals specifically with the Win32/intel platform,
similar attacks can most likely be carried out on the many other platforms
flash is available for. In particular, some of the methodology discussed might
be useful for constructing a robust exploit on Unix platforms as well as several
embedded platforms."

Maybe reading even a little before asking would be helpful.

Re:hmm. (1)

Lumpy (12016) | about 6 years ago | (#23115922)

"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.

flashblock ftw! (1)

verin (74429) | about 6 years ago | (#23115386)

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! (5, Informative)

LiquidCoooled (634315) | about 6 years ago | (#23115686)

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! (1)

morgan_greywolf (835522) | about 6 years ago | (#23115964)

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!

Sensasionalist Slashdot Headline Strikes Again! (0)

Anonymous Coward | about 6 years ago | (#23115400)

First of all, this isn't just a null pointer exploit. Sure, it's a complicated and quite impressive exploit, but it isn't going to open the floodgate to new exploits. This may lead to some deeper analysis of potential flaws by researchers, but in all likelihood, any exploit will be too complex for much practical use.
Also, this is in no small part due to questionable code in Flash. Reading the article, it seems there are at least FOUR places in the code that have mistakes, and each one of them should jump out at the developer and scream I AM A POTENTIAL VULNERABILITY! The fact that they got exploited just means that crappy software is exploitable, but hey, we already knew that, right?
Null derefs still are not exploitable and will continue to be not exploitable.

hang on... (1)

highwaytohell (621667) | about 6 years ago | (#23115422)

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

Re:hang on... (1)

4D6963 (933028) | about 6 years ago | (#23115546)

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.

Why the java icon? (4, Interesting)

LarsWestergren (9033) | about 6 years ago | (#23115448)

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 [slashdot.org] 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? (2, Insightful)

Roofus (15591) | about 6 years ago | (#23115458)

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? (5, Insightful)

ChunderDownunder (709234) | about 6 years ago | (#23115534)

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? (1)

LarsWestergren (9033) | about 6 years ago | (#23115848)

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 [mozilla.org]... :)

Re:Why the java icon? (0)

Anonymous Coward | about 6 years ago | (#23115888)

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.

Yeah... how about the following sentence?
"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."

Hmm. "Growing, digest, concern". They should tag this article "Microsoft" too just to be on the safe side.

Re:Why the java icon? (1)

baadger (764884) | about 6 years ago | (#23115598)

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? (1)

Ox0065 (1085977) | about 6 years ago | (#23115786)

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...

Crap factor 11 Captain? (2)

Nomen Publicus (1150725) | about 6 years ago | (#23115536)

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?

Could someone please... (2)

capn_buzzcut (676680) | about 6 years ago | (#23115634)

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

Re:Could someone please... (0)

Anonymous Coward | about 6 years ago | (#23115710)

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


So you want to explain it to your mom?

Pedantic (1)

noidentity (188756) | about 6 years ago | (#23115700)

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).

NULL Pointer Exploit Excites Researchers (0)

Anonymous Coward | about 6 years ago | (#23115728)

NULL Pointer Exploit Excites Researchers
In other news, "Researchers Need to Get Out More"

NoScript in Firefox (1)

A Pressbutton (252219) | about 6 years ago | (#23115828)

Plugins Tab

Switch on Forbid Macromedia Flash

Switch on Apply these restrictions to trusted sites too

Click OK.

Say goodbye to YouTube :)

Slashdot's slow, Dowd's a genius. (0, Redundant)

Rudd-O (20139) | about 6 years ago | (#23115932)

I read this two days ago at the source that broke the news. I have two things to say:

- Dowd's a freaking genius.
- Slashdot's a slowpoke.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...