User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

I don't have an isolated reproduction; but right now on my profile, enabling port authority crashes the browser within one second.

This has been kicked around as a bug in Port Authority; however this should not be possible. An addon that can cause a native crash has a very good chance of being able to break out of the sandbox and defeat all the permissions checks

Someone else is reporting a reproducible version here: https://github.com/ACK-J/Port_Authority/issues/22

Actual results:

No idea what changed to have it start happening

Expected results:

It should not be possible for an addon implemented in .js and .css to crash the browser.

Could you please give us a link to the crash report for this crash? You can find a link in about:crashes. Thanks.

Sorry, didn't realize those were externally usable links.

https://crash-stats.mozilla.org/report/index/571ee94d-f14d-492a-8d29-803780220612

Thanks.

The crash reason is this: MOZ_CRASH(IPC message size is too large), for the message PBackgroundIDBCursorParent::SendResponse(). This is a "safe" crash so I'm going to unhide it. Unfortunately, both web content and extensions can cause us to generate very large messages which we refuse to send by crashing. Maybe some work on the IndexedDB side could mitigate this issue. The extension itself also might be able to send less data at a time. I don't know how this message works exactly.

There's a reason why I filed this as a security bug. At work we run software that has to talk on '90s protocols, secured by a combination of VPNs and Firewalls. The security of the scheme was reasonable, until someone decided to permit JS from external domains to open websocket connections on localhost.

Nobody had ever managed to construct an attack that worked via <IMG SRC=""> due to restricted character set; however the websocket headers partially under attacker's control changed the result. The connections from the well known Lexus Nexis fingerprinting JS library actually started messing with our medical records software.

The security model of the software is, and has always been, either you can run code the computer or you cannot. Essentially nobody considers the case of running untrusted code on the computers running it that can make network connections, and the protocol cannot change anymore due to the next version from the standards body being rejected by the market as completely unusable (and it was).

Crashing the parent process is bad.
I wonder why the extension ends up sending so large data or is it some database corruption like https://github.com/ACK-J/Port_Authority/issues/22 hints?

Hmm, AFAICT Port_Authority does not even use IndexedDB but only local storage to store JSON?

(In reply to Jens Stutte [:jstutte] from comment #6)

Hmm, AFAICT Port_Authority does not even use IndexedDB but only local storage to store JSON?

The usage is consistent with the webext storage.local API as implemented on top of IndexedDB where a special container id is used to store the data on behalf of the add-on origin but in a location that's not directly available to the extension: https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ExtensionStorageIDB.jsm

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #5)

Crashing the parent process is bad.
I wonder why the extension ends up sending so large data or is it some database corruption like https://github.com/ACK-J/Port_Authority/issues/22 hints?

I would have to do a deeper analysis, but I guess there's a bug in the calculation of cursor response size. We do have checks which are supposed to prevent sending IPC messages larger than the limit.

Set release status flags based on info from the regressing bug 1168606

Set release status flags based on info from the regressing bug 1168606