modrobert @modrobert@social.cleverlibre.org

I don't know if this is a controversial opinion, but I will state it anyway:

I believe that the CVE system has some serious deficiencies. In particular, using the same system for both user-facing products and third-party libraries is problematic to the point of actually reducing overall security in the industry.

Let me give an example: Let's say you run a self-hosted piece of server-software written in Java. Let's call the product "Foo". You use something like Sonatype to monitor vulnerabilities in the software you use.

You happily run Foo for a few months and CVE-2023-0001 is reported on product Foo with a CVSS score of 9.9. In this case the system works great because you can now patch Foo as soon as possible, and in the meantime you can look at the remediation procedure documented in the CVE report to determine how much of a hurry you are in.

But that's unfortunately not what happens. What you are actually going to see is hundreds of vulnerabilities of varying severity reported not just on Foo as a product, but on every single third-party library that the product Foo happens to use.

Let's say that Foo generates SVG from a template and then uses a library to convert said SVG into images before sending them to the client (never mind that seems like a stupid solution, just go with it). And then a CVSS 10.0 appears because there is an RCE when passing specially crafted SVG data to the library.

Now you have Sonatype reporting that you have a severity 10 issue with the workaround static "upgrade this library". This information would be useful for the developer of Foo, but not for the user.

In fact, the developer may already have investigated this and downgraded the score since the library is never used to process untrusted input.

What this means is that as a user of some piece of software you will feel a lot of pressure internally to pursue CVE reports that are in fact not relevant, but since it shows up in your scan you have an obligation to do this, and check with the vendor to ask about the root cause of these results. This takes time and energy away from your real job: To keep your infrastructure secure.

I lay the blame for this happening squarely on the bad organisation of the CVE database, and I really wish there was a better way. Unfortunately right now it's all we have.

#cve #infosec #cvss

not visible: the glitching mosfet

firstly because I don't want nintendo to DMCA me, and secondly because my soldering was really bad and I knocked one of the caps off...

💥 radare2-5.8.4 is out! and it comes with some exciting changes, read this thread to learn about it!

https://github.com/radareorg/radare2/releases/tag/5.8.4

Periodic table of Linux distros /cc @Ange

OK, this is annoying. I made the mistake of using Git on Windows. I generated a patch which I sent to a Linux machine to be merged.

Of course nothing worked.

Why? Well, first of all the entire file was UTF-16, because of course it was. Then there was CRLF line endings. That wouldn't be too much of a problem, except for the fact that the damn thing had somehow managed to save UTF-8 encoded characters, parsed as Latin-1 and then stored as UTF-16.

I had to change all the broken characters manually in the patch prior to merging it.

Why is encoding problems a thing in 2023? And why it it only Windows that suffers from it?