[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