4 ms·
It might be worth it to analyze a bit more. Like, what would be different if the software would be closed source and developers payed by companies? I think it
by vladms 3y ago
It might be worth it to analyze a bit more.
Like, what would be different if the software would be closed source and developers payed by companies? I think it would be at least as hard to notice such an exploit and sometimes it might be easier (if the company is located in your jurisdiction).
Maybe the current mindset of assembling programs could be improved. There is a trend in some architecture to separate everything in their own container and while I don't think it can be directly applied everywhere that model gives more separation for cases like this. Engineering is an art of trade-offs and maybe now we can afford making different trade-offs than 30 years ago (when some things where decided)
- dakiol 3y agoDoes any private Microsoft/Google/Apple/whatever program have any backdoors? We don’t know and we will never know. At least with open source we are able to detect them.
- microtonal 3y agoI don't think this is necessarily true. People do a lot of reverse engineering of proprietary OSes and a lot of vulnerabilities are found that way (besides fuzzing). And the tooling for reverse engineering is only getting better. Also, let's not forget that this particular backdoor was initially found through behavioral analysis, not by reading the source code. I think Linus' law "given enough eyeballs, all bugs are shallow" has been refuted. Discovering bugs does not scale linearly with eyeballs, you need the right eyeballs. And the right eyeballs are often costly. If your implicit premise that having the source code available makes it easier to analyze code than closed source, you can also flip the argument around: it is easier for bad actors to find exploitable vulnerabilities because the source code is available. (Note: I am a staunch supported of FLOSS, but for different reasons, such as empowerment and freedom.)
- shzhdbi09gv8ioi 3y agoYes, and they are eventually discovered by reverse engineering. Example: https://en.wikipedia.org/wiki/NSAKEY https://en.wikipedia.org/wiki/NSAKEY
- beagle3 3y ago… and everything old is new again. DJB’s qmail, written in 1995, was made of 5 distinct processes, owned by different users, with no trust among them. Coincidentally, it was the MTA with the best security record for more than a decade (and also the most efficient one). It would have likely had a similar record even if it was only a monolithic process - because DJB - but it was built as 5 processes so even if one falls, the others do not.
- patchtopic 3y agoit was also essentially unusable without a crapload of third party patches that DJB would not include into the master release, but yes it was quite secure :-)
- Anarch157a 3y agoAnd it was highly vulnerable to denial of service attacks. It didn't check if the mailbox was valid during the envelope phase, so it would queue basicaly everything, then check the mailbox and send a bounce if necessary. Sending thousands of messages to random boxes (dictionary spam attack) would queue thousands of bounce messages that would be rejected by the (faked) sender domain, bringing the Qmail server to it's knees. As me how I know this... Thing is, in most companies, is cheaper and more efficient to deal with a sporadic vulnerability than having your e-mail system DOSed every other week. This is the kind of compromises that normal people and companies have to do all the time, but radicals and cryptopunks like DJB can't seem to understand. Sure, he's a brilliant mathematician and cryptographer, but his grasp of reality outside academia seems very flimsy, IMO.
- beagle3 3y agoMy qmail setup in 2000, on a humble beige box, was occasionally under a “thousands of bad addresses” attack, but I only found out about it a few days later while reviewing the logs. There surely was a threshold where it would be down on its knees - but “thousands” and even “tens of thousands” wasn’t it. The exchange server it replaced, though, would crash and burn very often, for a variety of reasons.
- discreteevent 3y agoGoogle's Fuchsia OS looks promising but it doesn't look like (or something like it) will go anywhere until the world accepts that you probably have to build security into the fabric of everything. You can't just patch it on.
- microtonal 3y agoI think Google has given up on Fuchsia, outside some specific domains, right? I think currently even Android, iOS, and ChromeOS have far better security than most desktop and server OSes. I think of the widely-used general purpose OSes, only macOS comes fairly close because it adopted a lot of things from iOS (fully verified boot, sealed system partition, app sandboxing for App Store apps, protected document/download/mail/... directories, etc.).
- udev4096 3y agoQubesOS is the closest we have, in terms of better security model, in the desktop area
- ta1243 3y agoCompanies are infiltrated all the time [0] However the incentives even if a company detected the infiltration is to keep quiet about it. Lets say that a closed source "accessd" was backdoored, a database admin notices the new version (accessd 2024.6 SAAS version model 2.0+ with GPT!) is slower than the previous version, they put it down to enshittificaiton. Or they contact the company who has no incentive to spend money to look into it. There's no way the database admin (or whoever) can look into the git commit chain and see where the problem happened. [0] https://rigor-mortis.nmrc.org/@simplenomad/112184869681420177 https://rigor-mortis.nmrc.org/@simplenomad/11218486968142017...
- pxeger1 3y agoThere isn’t much closed source software which is depended on as heavily as things like xz. The only one I can think of is Windows, which I think it’s safe to assume is definitely backdoored.