I read from the author of cURL (basically a very popular tool for a variety of tasks related to communicating with servers) who recently found out that someone filed a CVE relating to his project. This basically means someone has, or at least claims to have found a security issue in cURL. With cURL CVEs are apparently always filed by the maintainers of the project itself, but I don’t think it’s uncommon for other’s to do it as well. Depending on how severe the issue is the reports get different ratings. Some exploits are very hard to abuse and lead to only minor issues so they get a very low rating. Others are might be easy to exploit and can lead to unauthorized access to a server or privilege escalation. The latter then obviously get a higher rating with ten being the maximum. In case of cURL a ten or close to that would be a big deal since an issue like that affects millions of devices and users. Because of that severe bugs usually get disclosed directly to project maintainers so they can be fixed before anyone can abuse them. On the other hand such exploits can also be sold to malicious actors for a lot of money. Long story short in this case the person that filed the CVE found a bug where a timeout could overflow and wrap around. So it wasn’t a severe bug and it had already been fixed. So not only was a CVE created for a minor bug, but it was also rated as a 9.8 out of 10. I’m not sure who does the rating, if it’s the person submitting the CVE or the NVD, but the rating is obviously completely wrong.
That was basically the blog post. Now this wasn’t the first time this has happened and it probably won’t be the last. Disclosing CVEs and keeping them in a database is useful, but whoever is working at the NVD is apparently not giving it his all. Maybe they just assume that people always do their due dilligence before submitting their findings.
I’ve seen this happen before. The other time I’ve seen this happen was with OBS Studio. In this case someone claimed that using the word “password” in one of the language files was a security issue. The person that filed the bug report was so fucking dense that they really thought that some words in a text file would be a security issue. He picked out two random lines from the Spanish localization as an example. The issue was initially just closed because no one knew how to respond. After this he commnted with “How is this closed as completed , ??”. After someone explained to him how ini files and localization works he just answered “thanks for the clarification”. Someone else then mentionted that there’s been a CVE filed regarding this “issue”. As a response to this the reporter doubled down on his initial claim and admitted that he found the “issue” with a script. He also admitted that he filed the CVE because his issue was closed without any comment. If it wasn’t clear before that the reporter is fucking retarded it should be now.
So apparently who’s just smart enough to not choke on his own spit can file CVEs. In this case the CVE didn’t receive and grading and was later rejected. From the issue comment it looks like the authors of OBS requested this, so if they hadn’t done that there would’ve been a chance that this CVE would’ve stayed and it might even have gotten a rating.
The thing is that there is technically a potential security issue in OBS related to saving credentials in plain text. The program saves stream keys unencrypted on the hard drive. The devs are aware of this and the plan seems to be to use OS dependend solutions for storing sensitive data. This brings me to the other point: Cookies. They’re technically sensitive data. Most people use them so they don’t have to log in every time they go to YouTube. For that cookies are pretty useful. The problem is that they are usually saved in an unencrypted database somewhere on your harddrive. That’s how most browsers work. I’ve always found that strange especially considering that browsers have had master passwords to encrypt your saved passwords for a while. After searching a bit I’ve found out that this password is not used to encrypt cookies. I’m not sure why that is, my only guess is that it would be too slow or inefficient. When looking for an answer I found someone on Stackoverflow saying stealing cookies isn’t really an issue. Well fast forward a couple of years and there’s a common type of maleware that looks for almost every browser out there (except Librewolf, security by obscurity working once again) and steals all cookies as well as login information. The former then is used to steal your session and log into your accounts. This process was most likely used to prop up all those livestreams on YouTube that advertised Tesla related crypto scams. Considering that some bigger channels were affected by that one could say that this method was extremely effective. Currently they seem to have mostly stopped so it seems that after LTT was hit by it Google finally was forced to take some action. Doing some basic verification before accepting a cookie for skipping the login process really shouldn’t be that difficult so it surprises me that this kind of exploit ever even worked. In terms of security you’d rather ask a legitimate user to log in one extra time than let some malicious actor just waltz in because they have the correct session token.
TLDR: Databases aggregating CVEs should probably spend some extra time before accepting and grading issues and encrypting cookies stored on the harddrive and doing some additional verification to make sure that someone logging in with a cookie is actually still the same person is probably a good idea.