26603 - security audit of mozilla code

Status: VERIFIED FIXED

(Core :: Security, defect, P3)

Description

[Dan Mosedale (:dmosedale, :dmose)]

I was reading through a security advisory recently, and started thinking about
the recent landing of nsIFile and it occurred to me that it probably be a good
idea to do some basic code-auditing like checking for symlink-races.  After a
bit more thought, I realized this is really just an instance of something
larger: an overall code audit.

One possible way to structure this is to have some sort of public "Crack
Mozilla" campaign shortly before final release.  Splash mozilla.org and
mozillazine, encouraging people to help us audit.

Thoughts?

Comment 1

[Matthew Tuck [:CodeMachine]]

If I can get a stuffed green Moz out of it, I'll certainly try!

Comment 2

[Mike Shaver (:shaver emeritus)]

Security is mstoltz's bag, though I'll definitely take it back if he doesn't
think that data coming out of such an audit can be discussed publicly.

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Good idea - Let's do it. Shaver, let's work together on planning this. I suggest 
post-PR2, simply because I'm swamped right now and so are many Netscape engineers 
who should contribute to this. Marking M18.

Comment 4

[Dawn Endico]

moving from architecture to browser product. adding arch keyword.

Comment 5

[Jesse Ruderman]

We [note how I waste no time before abusing pronouns] would need to define what 
level of security we are aiming for before unleashing the slashdot effect on 
our helpless lizard.  In an ideal world, webpages would be able to do little 
else than be displayed and interact with the user within a small, defined 
space, but traditionally, Netscape and Internet Explorer have promised far less 
than this and even contained bugs allowing for the execution of arbitrary code.

Categories of security holes might include holes that allow pages, e-mails, or 
newsgroup postings to:

1.  execute arbitrary code
2.  view arbitrary content belonging to user
3.  block mozilla from loiding in the future (homepage excluded?)
4.  determine or reveal user's identity when not wanted (images in mail)
5.  edit or delete cookies for other sites
6.  view history, cookie lists, or specific cookies
7.  abuse another site's trust of user (cross-site posting)
8.  abuse user's trust of another site (client-side trojans)
9.  exploit user's nonzero reaction time to make him/her run arbitrary code
10. glean information about user's computer (cpu speed, available ram)
11. finley monitor cpu usage by other programs
12. crash an operating system
13. freeze an operating system (hog cpu very well)
14. hog system resources other than cpu (ram, widgets)
15. crash mozilla
16. freeze mozilla for ten seconds or more
17. make it impossible to exit mozilla normally

Comment 6

[Jesse Ruderman]

> stuffed green Moz 

Better yet, a stuffed green Moz signed by the person at fault for the hole <eg>

Comment 7

[John Unruh]

Assigning QA to czhang

Comment 8

[ekrock's old account (dead)]

[nsbeta3-] (eric & beard).

Comment 9

[Gervase Markham [:gerv]]

shaver, mstoltz - is one of you going to run with this?

Gerv

Comment 10

[Mitchell Stoltz (not reading bugmail)]

I'm going to try and do a series of (Netscape internal) security reviews in the 
post-PR3 period. I could use some advice on how to get the Mozilla community 
involved as well.

Comment 11

[Gervase Markham [:gerv]]

If you mean on a code level, a post to the NGs and a message on Mozillazine 
asking for developer help is about all you can do. If you want people to beat on 
it from the outside, same as above, but we could do wider publicity - security 
mailing lists, etc...

Gerv

Comment 12

[Mitchell Stoltz (not reading bugmail)]

Adding rtm keyword as these security review meetings will take place after PR3.

Comment 13

[David Krause]

How are we doing on format string bugs?  Is there some type of automated program
or does this have to be checked by hand? :(

[david@ender mozilla]$ find mozilla -type f | xargs egrep
'(sprintf|strcpy|strcat)' | wc -l
   3872

Comment 14

[Mitchell Stoltz (not reading bugmail)]

What sort of bug are you referring to? And why can't you use lxr.mozilla.org to 
do the serach?

Comment 15

[David Krause]

Format String Attacks: http://www.guardent.com/rd_whtpr_formatNewsham.html
Also seen all over bugtraq recently.

I guess I could use lxr, but a find command seems to work just as well.

Comment 16

[selmer (gone)]

Not sure this should have been nominated for rtm per-se.  It's a good thing to
do, but the scope seems pretty large for the time that remains.  Getting the
community involved ASAP would be a good thing regardless of the timing for the
branch release.  If we have any fire drills, we might take the results of this
into account as well.  Does it make sense for this to remain rtm nominated?

Comment 17

[Ben Bucksch (:BenB)]

Surely the nomination should stay, but I agree that it's by far too late to
"fix" this bug.

Comment 18

[Mitchell Stoltz (not reading bugmail)]

At the time, I marked this rtm to remind myself to work on this during the rtm 
time frame. I nay case, I wasn't planning to mark it Fixed until it was done to 
my satisfaction, which isn't going to happen by rtm, at any rate. Should I remove 
rtm, or should I have someone minus it? Or does it really matter?

Comment 19

[selmer (gone)]

rtm- to get this off the radar.

Comment 20

[John Unruh]

Mass changing QA to ckritzer.

Comment 21

[Mitchell Stoltz (not reading bugmail)]

Mass adding mozilla0.9 keyword (mass changing milestone doesn't seem to work).

Comment 22

[Ben Bucksch (:BenB)]

I'm (also) scared, that Mozilla might still contain traditional security
problems, like buffer overruns (no concrete examples, but potentially all code
handling net-content in char*s), symlink attacks (libmime writes lots of files
to /tmp - I didn't check, if it's actually vulnerable) etc..

Comment 23

[Mitchell Stoltz (not reading bugmail)]

Ben, can you look for these? Or encourage others? I'm going to see about 
reviving Netscape's bug bounty program, so there may be some reward in it...

Comment 24

[Ben Bucksch (:BenB)]

This is a pretty huge project. I can certainly encourage, but I can't do
everything (anything?) myself.

Frist, we'd need a plan :-). What exactly has to be done? Where are tutorials on
the web, so people without background can help? Then, post this as project
(newsgroups, mozillazine, bugtraq?), with code sections (probably modules or CVS
dirs) for which people can sign up.

Bug bounty? "Find a bug and get 1,000$"?

Aren't there automatic checkers for overflows, which cover at least many cases?

Comment 25

[Ben Bucksch (:BenB)]

Seems like I guessed quite good :)
<http://home.netscape.com/newsref/pr/newsrelease68.html>.

Comment 26

[Mitchell Stoltz (not reading bugmail)]

Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.

Comment 27

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 28

[Ben Bucksch (:BenB)]

Resetting Milestone (due to mass-change) and adding mozilla 1.0 keyword.

Comment 29

[Mitchell Stoltz (not reading bugmail)]

OK, this review is underway and is being tracked elsewhere, so I'm going to
close this bug. If you'd like to help with this effort, take a look at
http://www.mozilla.org/projects/security/components/reviewguide.html
or email [e-mail] with your suggestions.

Comment 30

[bsharma]

Marking verified as per above developer comments. The QA team is also involved
in this initiative. Please contact [e-mail] if you have any testing
issues or want to help in the testing area.

Comment 31

[Ben Bucksch (:BenB)]

Repeating my question from
<http://bugzilla.mozilla.org/show_bug.cgi?id=40756#c21> at Jun 4th:

mstoltz wrote:
> this review is underway and is being tracked elsewhere

Where is tracked?