Their products are flawed not just because they're badly implemented - which they are - but because they are based on a stupid idea. The idea that you improve your IT security by adding more complexity. Doing the opposite is the right approach. But you can't sell that as a product. (You can still sell it, but it's not something you just plug into your network and get security magically.)
Actually, the value of Citrix rose after that: https://www.marketscreener.com/quote/stock/CITRIX-SYSTEMS-INC-4863/ These things have no consequences for these companies, it's a completely broken market. I'm reading news that crowdstrike's value dropped, I have doubts that this will be permanent.
I'm mentioning citrix specifically because it really boggles my mind how they can be still in business. In case you don't remember, there were countless gov entities, hospitals, and what not, hacked in 2020, due to a really epic fuckup by citrix. It was a flaw they knew about, and hadn't provided a fix, only an unreliable workaround that sometimes didn't work.
Honestly, if we could get that one basic message out, that if their IT security is based on more complexity, not less, that they're doing it wrong, maybe we could start putting crap companies like crowdstrike or citrix out of business.
Let's cut the bullshit and spell out a few things. The IT security industry is about as trustworthy as the food supplement and vitamin industry, but somehow they escaped the same reputation. Their products are overwhelmingly based on flawed ideas, and the quality of their software is exceptionally bad. And while not everyone will agree with the harshness of my words, I'll say this: Essentially everyone in IT security who knows anything in principle knows this.
In Brandenburg ist morgen auch Kommunalwahl, also auch in Potsdam, und das ist vielleicht ein guter Zeitpunkt darauf hinzuweisen, dass der Gastgeber des rechtsextremen "Remigrationstreffens" immer noch im Vorstand der CDU Potsdam ist.
Today, 16 years ago, Debian published a security advisory announcing CVE-2008-0166, a severe bug in their OpenSSL package that effectively broke the random number generator and limited the key space to a few ten thousand keys. The vulnerability affected Debian+Ubuntu between 2006 and 2008. In 2007, an email signature system called DKIM was introduced. Is it possible that people configured DKIM in 2007, never changed their key, and are still vulnerable to CVE-2008-0166? https://16years.secvuln.info/
In case anyone from @1password is reading this, you may want to get in touch with me. I have reported a security vulnerability via their bugbounty program, and bugcrowd's staff thinks it's "not applicable", in my view clearly misinterpreting the program's rules. I am pretty sure it's something they want to address. I may consider other means of disclosure if this is "not applicable" for their bugbounty program..
@darnell@deanbetz I did some experiments with ad spending (low amounts) to push some of my articles. Facebook always rejected them as political, even though they were usually very technical, but climate-related.
I have a story to tell that is relevant to the xz-utils thing that just happened. I'll probably write this up properly later, but I'm in pre-vacation mode so it may take a while . We have a problem with the way we develop and then distribute FOSS software, and both stories show that. A while ago I looked at the testcases of a widely used library implementing a widely used data format. There was one file that was... strange. 🧵
I wanted to disclose this eventually, but then a new version of that library came out and fixed the bug. And plenty of others, and well, people crash parsers for data formats from hell all the time. And I had some concerns that it would sound like I wanted to ridicule the dev, which wasn't my intention at all. But I already thought there's a deeper story here than someone accidentally leaking a PoC for an unfixed vuln. Why can this even happen?
I contacted the responsible project, but I never got an answer and never really got to the bottom of this. But here's what I think happened: This was a proof of concept file for a yet unfixed and undisclosed vulnerability. It appears the developer already had a testcase for that bug in his local copy of the source tree. And then created the tarball from that source tree. And by doing that leaked a PoC for a zeroday. FWIW, it was "only" a DoS bug. But still.
That file was named similar to the other testcases, but it was not used in any test. And if you fed that file into anything using that library, it would either crash or cause enormous CPU spikes. And most interestingly: This file was nowhere to be found in the project's git repository. It was *only* in the tarball.
This creates a situation where even when the "many eyes" principle works, i.e. people are actually looking at the code, and at code changes and commits, you still have a path to a compromised package. Because noone checks how this git repo turns into a tarball. Because noone can, as nothing is standardized or reproducible. I can tell noone does for one of the most important libraries to parse one of the most important data formats, because of the story I just told you.
Pretty much everyone develops code using Git these days, or some other SCM (some don't, there's this mail server, but I disgress). But people distribute code in tarballs. How does a Git repo become a tarball? The answer may disturb you. It's basically "every dev has some process, maybe some script, maybe some commands they remember". Nothing is reproducible, nothing is verifiable.
Given that I see calls for better support for those random opensource devs that happen to maintain some of the most important pieces of software on the planet: a good friend of mine is maintaining expat - possibly the most important+popular xml library out there - and he has a message in his latest changelog that you may want to read: https://github.com/libexpat/libexpat/blob/R_2_6_2/expat/Changes
Hmja, dann jetzt auch Covid-positiv. Datenpunkt: Wir sind hier grad 2 Leute positiv im Nasentest, negativ im Rachen/Lollitest... gibt es da erkenntnisse zur aktuelle zuverlässigkeit von lollitests? Funktionieren die bei aktuellen varianten schlechter?