Mozilla has published a detailed analysis just over two months after the expansion mishap. The incident occurred on the first weekend of May and affected users of Firefox on the desktop, on Android or in the form of the Tor browser. Firefox reported that the installed extensions did not have a valid signature. As a consequence, Firefox disabled all (or all but the locally installed) user extensions. This was at the same time the protection against JavaScript, advertising and much more, which is ensured by extensions such as NoScript, UBlock and the like. Gate users were particularly hard to hit, their security depends crucially on the supplied extensions of the Tor browser. The incident was quickly referred to as armagadd-on-2.0. The cause of the problem was that the certificate with which Mozilla centrally signed all Firefox extensions had expired. It should have been renewed several weeks ago.
Eric Rescorla, CTO of Mozilla, is now presenting, several weeks later than originally intended, the results of the promised detailed analysis of the incident in a new post. Simplified, one could say that Mozilla overslept the expiration of the certificate. In fact, this was known to the staff of the team that created the signatures, but they falsely assumed that Firefox would not look at the expiration date for this certificate. Firefox’s testers did not notice the problem because there were no tests for it. The consequences of this are, on the one hand, better communication between the teams and better documentation and, on the other hand, extended tests.
Because the time was spent fixing the problem and creating a new version of the browser was a long one, as Rescorla once again explained, the way through the study system was first chosen to quickly install a “hotfix” in the browsers , Since this was only possible in conjunction with telemetry, Mozilla received telemetry data from users who supposedly did not want it. These data were subsequently removed by Mozilla. In the future, there should be a separate mechanism for such “panic updates”. He is already in work but should cause many users to resent again.
In the days following the incident, it turned out that the first correction delivered was flawed. And not just once, but eight times, which resulted in six browser updates in a short time. Obviously, the quality check was heavily neglected here, partly because of only developers, operators, and managers, but no testers were involved in the critical phase at the weekend. Mozilla also wants to handle this better in the future.
Source: https://www.pro-linux.de/news/1/27254/mozilla-ver%C3%B6ffentlicht-ausf%C3%BChrliche-analyse-der-erweiterungs-panne.html
Submitted by: Arnfried Walbrecht
Comments are closed.