[svlug] Restricting privileges

Rick Moen rick at svlug.org
Thu Jan 15 11:21:53 PST 2015


I'm just catching up on this thread.  I heartily second Sarah's notion of
restricting security-critical (meaning Internet-facing) desktop code's
rights using AppArmor.  Ubuntu package maintaner Kees Cook was doing an
excellent job of applying AppArmor to numerous specific Ubuntu packages
including Firefox -- along with a number of other hardening and
access-control techniques:

http://permalink.gmane.org/gmane.org.user-groups.linux.cabal/6396
https://wiki.ubuntu.com/Security/Features#AppArmor
https://wiki.ubuntu.com/Security/Features#Userspace_Hardening

Jesse expressed frustration about the security advisories concerning Firefox
[/Iceweasel], Thunderbird, Seamonkey, and Xulrunner being vague.  Yes,
they're vague.  ;->  I second Sarah's speculation that this is deliberate
vagueness for tactical purposes.  

Jesse wrote:

> So after all this deferencing of links I just do direct search.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1111737
> 
> NOW it says:
> """
> You are not authorized to access bug #1111737. To see this bug, you
> must first log in to an account with the appropriate permissions.

This is true for all of the Mozilla buzilla-database bugs linked from the
four CVEs in question -- even if you login to Bugzilla as a member of the
general public.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8634
 https://www.mozilla.org/en-US/security/advisories/mfsa2015-01/ viewable 
 https://bugzilla.mozilla.org/show_bug.cgi?id=1111737      access denied
 https://bugzilla.mozilla.org/show_bug.cgi?id=1109889      access denied
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8635
 http://www.mozilla.org/security/announce/2014/mfsa2015-01.html viewable
 https://bugzilla.mozilla.org/show_bug.cgi?id=1054538      access denied
 https://bugzilla.mozilla.org/show_bug.cgi?id=1026774      access denied
 https://bugzilla.mozilla.org/show_bug.cgi?id=1027300      access denied
 https://bugzilla.mozilla.org/show_bug.cgi?id=1072871      access denied
 https://bugzilla.mozilla.org/show_bug.cgi?id=1098583      access denied
 https://bugzilla.mozilla.org/show_bug.cgi?id=1070962      access denied
 https://bugzilla.mozilla.org/show_bug.cgi?id=1072130      access denied
 https://bugzilla.mozilla.org/show_bug.cgi?id=1067473      access denied
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8637   
 https://www.mozilla.org/en-US/security/advisories/mfsa2015-02/ viewable
 https://bugzilla.mozilla.org/show_bug.cgi?id=1094536      access denied
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8638
 https://www.mozilla.org/en-US/security/advisories/mfsa2015-03/ viewable
 https://bugzilla.mozilla.org/show_bug.cgi?id=1080987      access denied
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8639
 https://www.mozilla.org/en-US/security/advisories/mfsa2015-04/ viewable
 https://bugzilla.mozilla.org/show_bug.cgi?id=1095859      access denied
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8641
 https://www.mozilla.org/en-US/security/advisories/mfsa2015-06/ viewable 
 https://bugzilla.mozilla.org/show_bug.cgi?id=1108455      access denied

For most Linux-related stories, http://lwn.net/Articles/ is your best first
stop, but in the case of embargoed security information like what we see (or
rather, don't see) here, LWN merely gives you quick access to reliably bland
and deliberately semi-informative CVE text.

The significant ones appear to be 'memory safety problems and crashes'
reported by Christian Holler and Patrick McManus and enshrined in CVEs
CVE-2014-8634 and CVE-2014-8635.  The Mozilla Foundation Security Advisory
burbles vaguely about 'evidence of memory corruption under certain
circumstances' on account of 'several memory safety bugs in the browser
engine', with the not-at-all-surprising hint that 'scripting', i.e.,
Javascript, is essential to the potential exploit of these bugs, hence 
only a potential threat to Web browser and Web-browser-like contexts, and
not to Thunderbird.

You're probably not going to see any significant detail until the bugfix
releases have been out for a while.

Those who've attended my lectures on Web security may recall that my top tip
was to severely restrict what Javascript snippets are permitted to run and
to restrict what those snippets are permitted to do, e.g., using a
well-tweaked installation of NoScript.  My view remains unchanged in that
area.




More information about the svlug mailing list