SoylentNews is people
SoylentNews
The open source Pale Moon Browser's archive server suffered a data breach and infection.
From the Data breach post-mortem:
There has been a data breach on the archive server (archive.palemoon.org) where an attempt was made to sabotage our project by infecting all archived executables on the server with a trojan/virus dropper. This post-mortem report is posted to provide full transparency to our community as to what happened (as far can be gathered -- see below), which files were affected, what you can do to verify your downloads and what will be done to prevent such breaches in the future.
[...] A malicious party gained access to the at the time Windows-based archive server (archive.palemoon.org) which we've been renting from Frantech/BuyVM, and ran a script to selectively infect all archived Pale Moon .exe files stored on it (installers and portable self-extracting archives) with a variant of Win32/ClipBanker.DY (ESET designation). Running these infected executables will drop a trojan/backdoor on your system that would potentially allow further compromise to it.
The moment this was reported to me on 2019-07-09, I shut down access to the archive server to prevent any potential further spread of infected binaries and to start an investigation.
[...] Our data on this is limited, because in a later incident (likely by the same party or one other with similar access) on 2019-05-26 the archive server was rendered completely inoperable to the point of having widespread data corruption and being unable to boot or retrieve data from it. Unfortunately that also means that system logs providing exact details of the breach were lost at that time.
After becoming inoperable, I set up the archive server again on a different O.S. (moved from Windows to CentOS, and changed access from FTP to HTTP as a result considering Linux FTP can't be easily set up the same way and this server is purely a convenience service for users).
[...] This affected all archived executables (installers and portable exes) of Pale Moon 27.6.2 and below. Archived versions of Basilisk on the same storage server, although some would have already been present at that time, were not affected or targeted. Only files on the archive server were infected. This never affected any of the main distribution channels of Pale Moon, and considering archived versions would only be updated when the next release cycle would happen, at no time any current versions, no matter where they were retrieved from, would be infected.
Of note: only the .exe files on the server at the top level were affected. Files inside the archives (extract-able with 7-zip from the installers/portable versions or files inside the zip archives) were not modified.
If you never downloaded from archive.palemoon.org, you are almost certainly in the clear.
The post goes on to suggest that you verify your download by checking the code signing on the executables, where available, against .sig files provided, and/or against the SHA256 hashes provided.
It also notes:
Additionally, the infection is known to all major antivirus vendors and you can scan your downloads/system with your preferred mainstream antivirus scanner to verify the installers are clean.
Your humble editor has been using Pale Moon almost exclusively for four years, but has always practiced good download hygiene and always verified a download against the provided SHA256 hash. Also, since downloads were never from the archive server, it appears there was not even a potential to be affected in this case.
Out of an abundance of caution, Windows Defender was run and no infection of any kind was reported.
(Score: 4, Interesting) by ikanreed on Thursday July 11 2019, @06:39PM (2 children)
I've seen this complaint about every major browser(except, oddly, ie), and I wonder how much of it is that for performance reasons, every open DOM needs to be actively traversible with fast updates to low level implementation in UI of that DOM, while every single website feels entitled to ship with as much bloat as they and their advertisors can manage.
(Score: 0) by Anonymous Coward on Friday July 12 2019, @09:52AM
This is a chicken & egg situation. If browsers stop grabbing a few hundred meg for each tab, and perform accordingly, websites will need to be more visitor-system friendly or face a drop in traffic. But the more horsepower made available the worse the sties can and will become.
(Score: 0) by Anonymous Coward on Saturday July 13 2019, @07:30PM
What you can try is use the 32-bit version of the browser. That way the browser can't use up all your RAM just because the browser developers are too retarded to care that some people actually want to their computers for more than just browsing.
You may find that the browser actually works fine or even better overall.
I did this after I realized that the browsers actually still worked fine for the same pages when installed on machines or VMs with a lot less RAM. When the browsers are in a system with less RAM they tend change their behavior to use less RAM rather than use up huge amounts of RAM for diminishing (or even negative) returns just because "it's there".
But when I last checked there's no option or setting to tell Firefox or Chrome to behave as if it's on a 4GB or XGB system. So my workaround was to use the 32bit versions.