Researcher breaks security sandbox in Adobe Flash
Bypassing security with mhtml
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
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 passing data to remote systems.
By design, the so-called SWF files are locked in perimeter that can't communicate with the outside world. That's intended to thwart malicious Flash content that would otherwise locate sensitive user data and send it to machines controlled by attackers.
Rios found that the measure can be circumvented using a file:// request to a network machine. After snatching sensitive data, an attacker can simply pass it along using the GET protocol to an address such as file://\\192.168.1.1. That works on local area networks. To pass information to remote servers on the internet, attackers can use various protocol handlers that haven't been blacklisted by Adobe developers.
One such protocol is the mhtml handler, which is available on Windows and can be used without any prompts.
“Using the mhtml protocol handler, it's easy to bypass the Flash sandbox,” Rios wrote.
Well, sort of.
An Adobe spokeswoman issued a statement that read:
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. In the majority of use scenarios, the malicious SWF file could not simply be launched by double-clicking on it; the user would have to manually open the file from within the application itself.
The company's security team has rated the bug “moderate.” ®
COMMENTS
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
titt
Only if you can guess the location of the file in the cache. glwt,

IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider