90% of you run an insecure version of flash
Last Friday, a new version of Adobe Flash came out which patched the most recent critical flaws in Flash Player. Yet because the update process isn’t automatic, most of you have not updated your Flash Player in your web browser. The fact that Adobe makes the manual update process a pain to use and forces you to install yet another download manager and tries to get you to install yet another browser toolbar doesn’t help. The end result is that most of your computers are vulnerable to websites that display malicious flash content.
Categories: Adobe, Security, Security news
It’s interesting how the focus for security is changing from operating systems to applications. Adobe really has to smarten up its act. I spot these kinds of problems with the Secunia scanner.
As Yogi Berra once said, “It’s deja vu all over again”.
Microsoft has prudently decided that Office 2010 should run in a sandbox. In today’s world, that makes sense. All the more so with the added complexity of XML, the likelihood that there will be exploits rises exponentially.
I take the approach with Linux that if the app connects with the Internet, it should be proactively ‘sandboxed’. Don’t trust the application writers to stay on top of security issues.
Thus, applications like Firefox, Flash, Adobe Reader are sandboxed with AppArmor.
There is a how-to here that I wrote for Firefox and Adobe Reader.
BTW, AppArmor is open sourced by Novell and is standard on Ubuntu Linux 9.04 and openSUSE 11.1.
So, the rule of the day is: Sandbox It!
Be Safe.
It’s funny, a few days ago i was reading an article about the Office 2010 sandboxing, and some “analyst” was railing about how Microsoft was “admitting that Office is insecure”. Well, to me, it was more like they were “admitting” that someone is always going to find an exploit in a product that large, so you might as well plan ahead. That’s like saying that the *Nix development teams out there “admit that *Nix is insecure” by the existence of tools like sudo, chroot jails, etc.
J.Ja
@Justin James
Case in point:
Codenomicon DEFENSICS for XML Finds Multiple Critical Security Issues in XML Libraries
Eccl. 1:9 “What has been is what will be, and what has been done is what will be done; there is nothing new under the sun”
@Dietrich Schmitz
LOLZ, I thought the whole argument (when I was criticizing XML) for XML was that it was supposed to be more secure. The other argument they used was that XML was plain text readable which is not true since most XML documents have to be compressed with ZIP which comes with its own security dangers in the ZIP parsers.
@George Ou
Yep. Remember? And how we would grill you!
“Those were the days. Yep. Yep. Yep. Rose Colleti.
(Happy Days)
@Dietrich Schmitz
.
Yup, you guys grilled me for criticizing XML. Hate to say it, but I told you so
@Dietrich Schmitz
Yup, I saw that one yesterday. Unreal.
J.Ja
Many books have been written about XML. The format is text so, if somebody is intent on creating a malformed document, there are an ‘infinite’ number of possibilities for making the parsing routines ‘choke’ and induce a side-effect buffer overrun.
I recall at least in one ‘shootout’ of Office vs OpenOffice, you were raising the ‘speed’ issue for Excel spreadsheets vs OpenOffice (XML) and load times.
Naturally when you open an OLE binary object store, which native EXCEL spreadsheets are, you have the ability to predetermine ‘offsets’ (based on record structures) to the location of metadata/data that a ‘SEEK_SET’ will read directly into memory.
XML requires the entire document be extracted from a pkzip archive, parsed into a memory hash of key/value pairs before even beginning to make use of–naturally that will slow things down. And when your spreadsheet example has 14 columns by some 14K rows, that will take some time–not exactly a ‘typical’ user worksheet.
In any event, you were a ‘good sport’ when we danced on you with football cleats and were pretty reliable for correcting yourself when we caught you in cross-fire.
That was always fun.
OK then, Sandbox it is.
@Dietrich Schmitz
But you are in essence admitting that I was correct to point out that XML is much slower and I was correct to point out that it has no security advantage.
Even for smaller documents, I really can’t stand looking at XML in a text reader. All the implementations I’ve seen strip out the verbose metadata and present the data in a rich form factor like HTML. There’s no reason to be that verbose even if you can compress it away, because you still have to decompress it and process it in the CPU and memory.