[Meego-security-discussion] Chromium browser security, installing Firefox 4 on MeeGo, and request for packaging

[Niels Mayer]

On Sat, Apr 16, 2011 at 11:07 AM, Rolf Offermanns <roffermanns at sysgo.com> wrote:
> FYI: https://bugs.meego.com/show_bug.cgi?id=16284

Thanks for filing the bug and sorry for not filing myself per Ryan's
request -- I was on vacation.

In addition, I'm proposing as 1.2 release blocker especially because of this:
https://bugs.meego.com/show_bug.cgi?id=16284#c1
...............................
The thing that really makes the non-sandboxing a showstopper is the following
CVE: http://www.adobe.com/support/security/bulletins/apsb11-07.html
...........
"A critical vulnerability has been identified in Adobe Flash Player 10.2.153.1
and earlier versions (Adobe Flash Player 10.2.154.25 and earlier for Chrome
users) for Windows, Macintosh, Linux, and Solaris, and Adobe Flash Player
10.2.156.12 and earlier versions for Android. This vulnerability
(CVE-2011-0611), as referenced in Security Advisory APSA11-02, could cause a
crash and potentially allow an attacker to take control of the affected
system."
...........

In fact, it was while I was trying to figure out how the aforementioned flash
exploit was owning my Linux systems that I discovered and started looking at
Chromium's "second class" sandboxing solutions for Linux in chrome, and even
worse, the total lack of sandboxing in MeeGo's chromium. It's why I switched to
firefox 4, which seems less vulnerable than chromium for Linux, and posted the
message about FF4 vs MeeGo's chromium issue to the lists:
http://lists.meego.com/pipermail/meego-security-discussion/2011-April/000100.html

................
Firefox4 may offer better sandboxing and security for Linux. In
contrast, it appears that chromium's sandboxing isn't necessarily
present on their Linux distributions , per
http://code.google.com/p/chromium/wiki/LinuxSandboxing and
http://code.google.com/p/chromium/wiki/LinuxSUIDSandbox ...

For Linux, it's possible that FF4 is actually more secure. Based on
https://wiki.mozilla.org/Electrolysis "already in use in Firefox to
isolate browser plugins like Flash, which fortunately means that users
are insulated from the instability of such plugins" (
http://arstechnica.com/open-source/reviews/2011/03/ars-reviews-firefox-4.ars
.......................

It's not clear that enabling "standard linux" security (see "Expected Outcome"
on this bug) will prevent the flash exploit mentioned above.  A proper fix for
this bug should consider enabling the seccomp sandbox per
http://lwn.net/Articles/346902/ and
http://www.imperialviolet.org/2009/08/26/seccomp.html ... but I guess getting
it to the same level of insecurity as the distributed google chrome for
linux/android is a good start (google ships vulnerable flash plugins with...
chrome browser for android and Linux).

-- Niels
http://nielsmayer.com

PS: after writing above, I realized seccomp wouldn't work for flash.
Even a reduced flash that could just play movies (w/ no camera/mic
access) could potentially do bad things against the dbus or the X
server. On a system w/ root-X server (not meego) this can be observed
in practice, perhaps via
http://www.invisiblethingslab.com/resources/misc-2010/xorg-large-memory-attacks.pdf
( http://lwn.net/Articles/399719/ ).

The problem with flash  in a seccomp sandox is summarized in the LWM
link I gave in the bug report:
........
One additional, important area that is not covered by the sandbox are
plugins like Flash. Restricting what plugins can do does not fit well
with what users expect, which makes plugins a major vector for attack.
Langley said that the plugin support on Linux is relatively new, but
"our experience on Windows is that, in order for Flash to do all the
things that various sites expect it to be able to do, the sandbox has
to be so full of holes that it's rather useless". He is currently
looking at SELinux as a way to potentially restrict plugins, but, for
now, they are wide open.
.......

The following suggests it's an X exploit that flash uses -- and that
flash needs sandboxing "from all sides" and not just the browser....

http://blogs.adobe.com/asset/2011/03/background-on-apsa11-01-patch-schedule.html
..............
Adobe Reader X Protected Mode (aka “sandboxing”) is designed to
prevent the type of exploit we are currently seeing in the .swf/.xls
attack from executing. Even if an attacker made the transition to a
.pdf container for the exploit, the sandbox would prevent the final
step of malicious software installation on the victim’s machine.
............