search

KawaiiBASIC / classilla

Automatically exported from code.google.com/p/classilla
0 stars 0 forks source link

Complete security audit through 1.7.12 by 9.3.1 #172

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The security audit must be complete by 9.3.1.

Original issue reported on code.google.com by classi...@floodgap.com on 24 Oct 2011 at 7:32

GoogleCodeExporter commented 9 years ago 
We need to audit 
http://www.mozilla.org/projects/security/older-vulnerabilities.html from the 
February 2003 update forward (inclusive).

Original comment by classi...@floodgap.com on 25 Feb 2012 at 3:05

GoogleCodeExporter commented 9 years ago 
https://bugzilla.mozilla.org/show_bug.cgi?id=51631

Original comment by classi...@floodgap.com on 25 Feb 2012 at 3:19

GoogleCodeExporter commented 9 years ago 
(and, due to regression caused, 
https://bugzilla.mozilla.org/show_bug.cgi?id=203629 )
https://bugzilla.mozilla.org/show_bug.cgi?id=183092
https://bugzilla.mozilla.org/show_bug.cgi?id=92773 (caps only)

This completes the update through July 2003 inclusive. Next: November

Original comment by classi...@floodgap.com on 25 Feb 2012 at 3:30

GoogleCodeExporter commented 9 years ago 
M220721 (disabled ppm in nsImageModule.cpp)
not vulnerable to M221526, 220257
M220122
not vulnerable to M217195, M217625
already applied M213012, M158049, M163549, M155114

next: Fixed in 1.6

Original comment by classi...@floodgap.com on 3 Mar 2012 at 8:37

GoogleCodeExporter commented 9 years ago 
already applied M228176, M227417 (current to 1.6)

not vulnerable to M246448, M162020
wow, this one is NASTY: https://bugzilla.mozilla.org/show_bug.cgi?id=244965 
(fixed)
M229374 (and M245066, which backs out M157644, which was on our tree from 
WaMCom)
M243699 (note that disk:// is not in OS 9)
not vulnerable to M242915, M241924
M240053 (OUCH!)

Rebuilding

Original comment by classi...@floodgap.com on 3 Mar 2012 at 10:24

GoogleCodeExporter commented 9 years ago 
M226278

Rebuilding

Original comment by classi...@floodgap.com on 3 Mar 2012 at 11:46

GoogleCodeExporter commented 9 years ago 
M234058
not vulnerable to M239122
https://bugzilla.mozilla.org/show_bug.cgi?id=86028 -- hard to exploit because 
of our script security but can be done
M236618
https://bugzilla.mozilla.org/show_bug.cgi?id=206859 -- yikes!

Rebuilding
Next: 1.7.1/2

Original comment by classi...@floodgap.com on 4 Mar 2012 at 12:52

GoogleCodeExporter commented 9 years ago 
M250180 (though we are undoubtedly not vulnerable in any reasonable 
configuration)
not vulnerable to M251381
M253121
M249004 (can't test well ... a little concerned about certificate importing)

Original comment by classi...@floodgap.com on 4 Mar 2012 at 2:25

GoogleCodeExporter commented 9 years ago 
not vulnerable to M235781, M231083, M254303, M256316
M245066
we are vulnerable to M250862 but it locks up the system, so I'm not sure how 
exploitable it is in practice. The patch does not apply. We will come back to 
it.
M255067
M257314
M253492 requires strings and is low risk: 9.3.2
not vulnerable to M257523 specifically, but it's safe and a good idea
M258005

Next: http://www.mozilla.org/projects/security/known-vulnerabilities.html

Original comment by classi...@floodgap.com on 4 Mar 2012 at 3:23

GoogleCodeExporter commented 9 years ago 
NV:
249332
251297
257308
262689. not correct, but not vulnerable.
264388
265728. a good idea, but not vulnerable, and doesn't apply.
268107
273498

V:
127450
262887
267263 (with SSLConnectFailed() patch)

all repaired
next: Mozilla 1.7.6

Original comment by classi...@floodgap.com on 25 Jun 2012 at 3:30

GoogleCodeExporter commented 9 years ago 
Fixing the caret completely is bug 287813 but I am scared of this patch for 
9.3.1. At least it doesn't steal focus anymore.

Original comment by classi...@floodgap.com on 25 Jun 2012 at 3:34

GoogleCodeExporter commented 9 years ago 
NV:
285438
282270 (this specific fault)
281284
279945
277574 possibly technically vulnerable but hard to trigger
275417
271732
277549 (we'd crash anyway in this situation)
260560 (poorly exploitable using OS 9 chrome)
241440
268483

Declined: (too complex for minimal gain)
271209

V and fixed:
285595
280664
280056
268059
277564
258048 (some parts already added in earlier version)
276720

Last patch is bug 103638 by way of 273699, but this is a big 'un and I'm 
pooped. Watch bug 296850. After that, next: 1.7.7

Original comment by classi...@floodgap.com on 26 Jun 2012 at 2:46

GoogleCodeExporter commented 9 years ago 
NV:
288688
289204
289675 (though not sure if this is just because of bad __proto__ implementation)
290036 (however, bandaid added anyway just in case)
290162
289083 (combo of no __define[GS]etter__ and Script())
289961

V:
290037
289074 (SCARY!)

need to fix 233142

next: 1.7.8

Original comment by classi...@floodgap.com on 28 Jun 2012 at 3:44

GoogleCodeExporter commented 9 years ago 
Actually, tomorrow we should do 103638 and 233142 before 1.7.8.

Original comment by classi...@floodgap.com on 28 Jun 2012 at 3:44

GoogleCodeExporter commented 9 years ago 
Both done (103638 was a monster but a scary bug that needed to be fixed). 
233142 doesn't work quite right but is not a vulnerability. next: 1.7.8

Original comment by classi...@floodgap.com on 29 Jun 2012 at 5:42

GoogleCodeExporter commented 9 years ago 
NV
290908
290949 as written, but partially implemented anyway just in case
293671 as written, but implemented anyway
291745
292499

V
290982

also fixed
crash for XSS testcase, 292691

Having trouble getting the data: URL exploit in 292691 to not work (it works 
100%).

Original comment by classi...@floodgap.com on 14 Jul 2012 at 12:26

GoogleCodeExporter commented 9 years ago 
Looks like M387979 (plus the SHEntry changes for 1.8 branch) fixes that, so we 
will attack that tomorrow.

Original comment by classi...@floodgap.com on 14 Jul 2012 at 2:26

GoogleCodeExporter commented 9 years ago 
Actually, it's M321299. This seems to have lots of regressions associated with 
it. :-/

Original comment by classi...@floodgap.com on 16 Jul 2012 at 1:18

GoogleCodeExporter commented 9 years ago 
After spinning my wheels, decided on the following:

// bug 292691
    PRBool isJavaScript, isData, isViewSource;
    if ((NS_SUCCEEDED(uri->SchemeIs("javascript", &isJavaScript)) &&
         isJavaScript) ||
        (NS_SUCCEEDED(uri->SchemeIs("view-source", &isViewSource)) &&
         isViewSource) || 
        (NS_SUCCEEDED(uri->SchemeIs("data", &isData)) && isData)) {
        // We're loading a javascript: or data: URL from session
        // history. Replace the current document with about:blank to
        // prevent anything from the current document from leaking
        // into any JavaScript code in the URL.
        rv = CreateAboutBlankContentViewer();

        if (isData) {
            // Classilla issue 172. A definitive fix for this requires we implement the Mozilla 1.8
            // SHEntry hacks in M321299 and frankly that has a lot of regressions associated with it. A
            // down payment is just to stop data: from loading from history. This is wrong, and has
            // its own regressions, but they are likely to be less than the alternative.
            return NS_OK;
        }

        if (NS_FAILED(rv)) {
            // The creation of the intermittent about:blank content
            // viewer failed for some reason (potentially because the
            // user prevented it). Interrupt the history load.
            return NS_OK;
        }
    }
// end bug

Original comment by classi...@floodgap.com on 19 Aug 2012 at 10:14

GoogleCodeExporter commented 9 years ago 
Somewhere along the way view-source broke. It might be that code, since it's 
loading from history, presumably.

Original comment by classi...@floodgap.com on 19 Aug 2012 at 11:16

GoogleCodeExporter commented 9 years ago 
It was that code. Commented out and it looks like the other changes were 
sufficient.

Work since then:

NV
294795
294799
295011
296397
296830
296850
289940. although a good idea, this is WAY too complex and not necessary for us.

V and fixed
298892
298934
295854
293331 (difficult to trigger but is vulnerable)
292591 (eeek)
292589

next: 1.7.12

Original comment by classi...@floodgap.com on 22 Aug 2012 at 2:16

GoogleCodeExporter commented 9 years ago 
1.7.12

NV
307185
307259

next: rollup advisory for 
http://www.mozilla.org/security/announce/2005/mfsa2005-58.html (completes 
1.7.12)

Original comment by classi...@floodgap.com on 22 Aug 2012 at 2:20

GoogleCodeExporter commented 9 years ago 
NV
300936. while we have the same code, we are NOT exploitable, and actually using 
the provided fix makes us CRASH!
296134
299518
303213
304754

V and fixed
297078
302263
306261, including our own unique vulnerability X-/

to fix next:
306804

Original comment by classi...@floodgap.com on 23 Aug 2012 at 3:41

GoogleCodeExporter commented 9 years ago 
306804 completed. next: 1.7.13 (man, that's a huge list)

Original comment by classi...@floodgap.com on 23 Aug 2012 at 3:57

GoogleCodeExporter commented 9 years ago

Original comment by classi...@floodgap.com on 29 Aug 2012 at 1:29

GoogleCodeExporter commented 9 years ago 
After discussion with users, it has been over 7 mo since the last Classilla 
release and there are very important fixes already landed (both security and 
otherwise). After 1.7.13 and other critical issues, 9.3.1 will be released. The 
followup for 9.3.2 and 9.3.3 will be issue 196.

Original comment by classi...@floodgap.com on 29 Aug 2012 at 1:30

GoogleCodeExporter commented 9 years ago

Original comment by classi...@floodgap.com on 29 Aug 2012 at 1:30

GoogleCodeExporter commented 9 years ago 
So far on 1.7.13:

NV
325991
328469
325947
327194 (290488)

V
328937 (317554)
327126, the underlying vulnerability, although not exploitable by testcase per 
se
328566, difficult to exploit on OS 9 in practice
325403
319858
320182 (269095, 286733)

Still quite a few to go.

Original comment by classi...@floodgap.com on 30 Aug 2012 at 2:48

GoogleCodeExporter commented 9 years ago 
NV
313373
312871
313236
313375
313370
313684
311025
311403
311455
293527 (impossible to exploit properly on Mac OS)

V
271194 (there's still an unrelated bug in the test case, but the page can't be 
interacted with anyway)

Original comment by classi...@floodgap.com on 2 Sep 2012 at 2:11

GoogleCodeExporter commented 9 years ago 
NV
315304 (290162)
313173 (we do not, and never will, support styled XUL because of chrome bustage 
risk)
311710 (ditto)
280769
311497
311792
312278
313276
313479
313500
313630
313724
313763
313938
325269

V
265736

296514/311024/311619/311892 (316589) is really scary and I can't fix it yet. We 
need to make our docshell stop the executing script because the changed 
principal propagates (witness the change in the title bar from bugzilla to 
google when it retrieves the cookies).

Original comment by classi...@floodgap.com on 2 Sep 2012 at 4:54

GoogleCodeExporter commented 9 years ago 
Actually, that is the wrong approach. We need to make the principal invariant 
so that the executing script remains within the former (now gone) principal and 
not the new one. Caps principals were rewritten in M83536 and then again in 
M216041. These should work in Classilla, but possibly just making Init(char 
*aCodebase) into Init(const char *aCodebase) and PL_strdupping it as in M216041 
might be enough.

Original comment by classi...@floodgap.com on 2 Sep 2012 at 6:42

GoogleCodeExporter commented 9 years ago 
I can't figure this one out, and it looks like the power supply on the MDD blew 
out tonight, so that ends working on this for awhile until I can sit down and 
disassemble it.

I have an ObjectPrincipalsFinder implemented in dom:nsJSEnvironment.cpp. When 
this is disabled, chrome scripts work, but the bug manifests. When this is 
enabled, chrome scripts appear unprivileged. The test that fails is not being 
done by nsSystemPrincipal::Equals. We need to look at nsScriptSecurityManager 
and see what chrome test is failing.

Original comment by classi...@floodgap.com on 3 Sep 2012 at 3:38

GoogleCodeExporter commented 9 years ago 
I'm spinning my wheels here. Let's just get what we have out.

Original comment by classi...@floodgap.com on 19 Oct 2012 at 1:33

GoogleCodeExporter commented 9 years ago

Original comment by classi...@floodgap.com on 19 Oct 2012 at 4:48