back to article Researcher breaks security sandbox in Adobe Flash

A security researcher has found a way to bypass a measure in Adobe's Flash Player that's designed to harden it against hack attacks. Billy Rios, a Google researcher who published the method on his personal website, said it circumvents the local-with-filesystem sandbox, which is supposed to prevent Flash files loaded locally from …

COMMENTS

This topic is closed for new posts.

Correct me if I'm wrong....

"An attacker would first need to gain access to the user's system to place a malicious SWF file in a directory on the local machine before being able to trick the user into launching an application that can run the SWF file natively"

So the local directory could be the IE cache, and the application could be IE with the appropriate adobe plugin installed? A cunningly crafted cunning website could do this?

I might be wrong though. I'm not 100% sure of how the "hack" works.

0
0

titt

Only if you can guess the location of the file in the cache. glwt,

1
1
Stop

One question....

...how much time were Adobe given before this was published?

Loads of time, little time ro no time?

If the latter, is this another example of Google staff releasing exploit info in a crappy way (conspiracy theories allowed).

More info on the background please.

0
0
FAIL

Hmmm

Who was it who said Flash was "bloated" and "buggy"?

Well now that there are serious problems for Windows users too, how does that make all you fanbois feel?

0
2
Silver badge

Security Sandbox

Adobe

not in the same memory space thanks.

0
0
Anonymous Coward

so..

So an example social engineering attack might be to compose such a file that refuses to be opened if it isn't saved locally, e.g. by providing the error message "Please save this file to your local machine and then open it from acrobat". I can well see many people falling for that one: it seems a fairly reasonable instruction to follow out.

0
0
Stop

Attracting Free Flames....

This morning I got a nice list of things to be updated for my Ubuntu 10 system, including this:

http://www.ubuntu.com/usn/usn-1035-1

I have a history of blasting M$, Adobe and others for their general lazy approach to bugfixing and I am a fan of Linux, nevertheless, being fair and trying to be objective is more enlightened than pure fanboyism.

I had a quick look into the most commonly used Free PDF base library and found a few calls to strcat, strcpy and the like. Also, C/C++ is in general an unsafe language and nobody should assume he or she will never make a dangerous mistake.

http://cgit.freedesktop.org/poppler/poppler/tree/poppler

Looking at this code one can see that there exists plenty of potential security problems in all these char* and non-smart pointer operations. The code looks generally quite good, but I would feel much safer if they used a string library which *always* checks bounds.

PDF has been known to be used as an attack vector for Chinese Intelligence operating against dissidents/separatists and what the Chinese can do, anybody else (let's say Pullach, TelAviv, Moscow, Rome, Paris, Langley) can do, too.

Even in the free software world there are very few commonly accepted rules such as "use vectors with array index checking" "use smartpointers which are automatically intialized to NULL" "use only string classes with bounds checking" etc. Too many developers will claim that they can't afford the overhead. In reality that overhead is minimal and must only be removed in very small and well-defined locations. By default, array bounds should be checked and pointers should be initialized to NULL. printf(), strcpy, strcat et al and char* poińters should be banned by default and only be allowed in exceptional cases.

If an exception to these policies must be made, a special keyword in the comments surrounding should announce/enclose this. This would allow reviewers to focus on these sections.

0
0
Megaphone

Lazy Coding in Poppler

Experienced programmers will note that the following piece of code from libpoppler (most Free PDF Readers use it), contains a lame attempt at security. Mind you, integers are often 32 bits long. That piece of code would accept something like

9999999999

and return something which definitely is not 9999999999, because

typedef unsigned int Guint;

and int is typically a 32bit integer, depending on the platform. I am not sure this is exploitable, but at they should "pro-actively" plug this hole.

//THE CODE:

Guint PDFDoc::strToUnsigned(char *s) {

Guint x;

char *p;

int i;

x = 0;

for (p = s, i = 0; *p && isdigit(*p) && i < 10; ++p, ++i) {

x = 10 * x + (*p - '0');

}

return x;

}

////////////////

reported problem to

Hib Eris <hib@hiberis.nl>

Jakub Wilk <ubanus@users.sf.net>

Ilya Gorenbein <igorenbein@finjan.com>

Srinivas Adicherla <srinivas.adicherla@geodesic.com>

Philip Lorenz <lorenzph+freedesktop@gmail.com>

who are listed in the header

0
0
Linux

10.2 Beta ?

Anyone know if 10.2 beta is included in this ?

1
0
WTF?

Ummm

"the so-called SWF files"

No, they really are SWF files. No so-called about it !

0
0

Down with this sort of thing.

Roll on HTML5, canvases, SGV and all that.

1
2
This topic is closed for new posts.

Forums