Closed Bug 1007269 Opened 10 years ago Closed 10 years ago

Categories

(Core :: Security: PSM, defect)

31 Branch
x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mwobensmith, Unassigned)

References

Details

The site https://www.ibikesports.com causes different behavior in mozilla::pkix-enabled builds.

Fx29 and Fx30, site is blocked with SSL error: 
Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate)

Fx31, default, we see a crash.

Fx31 with ocsp.require=true, error: 
The OCSP response contains out-of-date information. (Error code: sec_error_ocsp_old_response)

Fx32, default, the site loads successfully with mixed content plus SSL warnings: 
This web site does not provide identity information.
The connection to this website is not fully secure because it contains unencrypted elements (such as images).

For comparison, on Chrome, the site behaves like Fx32 - successfully loads with mixed content warning.

On Safari, it is blocked with the same cert revocation error as Fx29/Fx30.
There are two main questions: why does it crash and why does the site load on Fx32 when blocked on others?

Sadly I can't get an ASan build to get me a stack trace due to my own build issues.
The crash looks JS-related:

Assertion failure: !script()->formalIsAliased(i), at /home/keeler/mozilla-aurora/js/src/vm/Stack-inl.h:133

Backtrace:
#0  0x00007f1e34d3598d in nanosleep () from /lib64/libc.so.6
#1  0x00007f1e34d35824 in sleep () from /lib64/libc.so.6
#2  0x00007f1e303b241d in ah_crap_handler (signum=11) at /home/keeler/mozilla-aurora/toolkit/xre/nsSigHandlers.cpp:88
#3  0x00007f1e303c1341 in nsProfileLock::FatalSignalHandler (signo=11, info=0x7ffffc82bcf0, context=0x7ffffc82bbc0) at /home/keeler/mozilla-aurora/profile/dirserviceprovider/src/nsProfileLock.cpp:185
#4  0x00007f1e31b00aff in AsmJSFaultHandler (signum=11, info=0x7ffffc82bcf0, context=0x7ffffc82bbc0) at /home/keeler/mozilla-aurora/js/src/jit/AsmJSSignalHandlers.cpp:966
#5  <signal handler called>
#6  js::InterpreterFrame::unaliasedActual (this=0x7f1e18d8a3c8, i=0, checkAliasing=js::CHECK_ALIASING) at /home/keeler/mozilla-aurora/js/src/vm/Stack-inl.h:133
#7  0x00007f1e317f34b3 in js::AbstractFramePtr::unaliasedActual (this=0x7ffffc82c298, i=0, checkAliasing=js::CHECK_ALIASING) at /home/keeler/mozilla-aurora/js/src/vm/Stack-inl.h:541
#8  0x00007f1e3183321b in js::GetElemOptimizedArguments (cx=0x7f1e07f639a0, frame=..., lref=..., rref=..., res=..., done=0x7ffffc82e1a7) at /home/keeler/mozilla-aurora/js/src/vm/Interpreter-inl.h:409
#9  0x00007f1e3181da45 in Interpret (cx=0x7f1e07f639a0, state=...) at /home/keeler/mozilla-aurora/js/src/vm/Interpreter.cpp:2472
#10 0x00007f1e31811e09 in js::RunScript (cx=0x7f1e07f639a0, state=...) at /home/keeler/mozilla-aurora/js/src/vm/Interpreter.cpp:422
#11 0x00007f1e318290a7 in js::Invoke (cx=0x7f1e07f639a0, args=..., construct=js::NO_CONSTRUCT) at /home/keeler/mozilla-aurora/js/src/vm/Interpreter.cpp:494
#12 0x00007f1e316161d1 in js_fun_call (cx=0x7f1e07f639a0, argc=3, vp=0x7ffffc82f410) at /home/keeler/mozilla-aurora/js/src/jsfun.cpp:948
#13 0x00007f1e14b206cc in ?? ()
#14 0x00007f1e07f639a0 in ?? ()
#15 0x00007ffffc82f3e8 in ?? ()
#16 0x00007ffffc82f4e0 in ?? ()
#17 0x0000000000000000 in ?? ()

I think the OCSP issue will be fixed by bug 997509.
related to bug 1003161 ?
Keeler, do you have any idea why this site would load in Fx32 (and Chrome) but not the others?
(In reply to Carsten Book [:Tomcat] from comment #3)
> related to bug 1003161 ?

Looks like it.

(In reply to Matt Wobensmith from comment #4)
> Keeler, do you have any idea why this site would load in Fx32 (and Chrome)
> but not the others?

I believe it's due to the new OCSP decoder/verifier (i.e. it's a mozilla::pkix bug). The OCSP responder is serving a response that we consider to be too old. In the default configuration we discard such responses and continue connecting. However, since the response says the certificate is revoked, we should probably use that information and refuse to connect. I believe this is what the previous (NSS) OCSP implementation did. Bug 997509 should fix this issue for us.
Chrome doesn't do OCSP by default, and apparently this site's certificate isn't on their CRLSet mechanism, so they don't know the certificate has been revoked.
For purposes of this bug we'll ignore the site loading -- that's bug 997509 -- and just deal with the crash. The tested build would have already had the patch for bug 1003161 so that's not likely to be it, but Matt will try again to catch this in an ASAN build.
Depends on: 997509
Looks like it no longer crashes on today's build.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.