Code-Signing Certificate Lifetimes Shortened, Consolidating Power

Key Quotes

"We're beginning to see I'll be talking about another reduction in certificate length which has no justification and and this new feature saps smart app or sac smart app control that landed in windows 11 which cannot be turned off where you can't allow apps you trust or exceptions all of Microsoft's stuff has until now all of the windows defender you could say okay fine I want to dedicate this directory to things that you don't bother me about that's going away so so and users are being increasingly inconvenienced in the same way and for the same reason that we can't build light rail in California it's you know it's like it's diminishing returns it's the belief that we can apply our fancy technology to solve problems that where the where the presence of that technology creates a bigger problem than what it is trying to solve and and I we I think this is the year where we're going to begin to see I mean we're the signs have been there and we've been reporting this until now I think it's going to mature unfortunately like this year and next where things are going to be are becoming increasingly constrained in a in a mistaken belief that we're going to be able to fix this just by being more tricky by applying technology to where mistakes we're not really fixing mistakes much and the human factor is still there anyway"

Steve Gibson expresses concern about a trend of increasing restrictions and inconveniences in software and technology, likening it to over-regulation hindering progress. He argues that these measures, often presented as security enhancements, may create more problems than they solve and that the human element remains a significant factor in security failures. Gibson suggests this trend will likely intensify in the coming years.

"Nevertheless the certificate authorities have voted and decided that even safely stored code signing certificates must be renewed now much more frequently so I understand why this happened with TLS certificates because of issues with revocation right but there's nothing like that for code certificates right no no you could you know if so and and this is another part of the annoyance it's not as if this is actually going to prevent maliciously signed malware you're going to get companies posing as as reputable software publishers who obtain a code signing certificate and and establish a reputation very much the same way that that people who run forums see people creating accounts that are dormant for a while in order to sort of slip under the radar and then they start getting up to some mischief downstream at some point same thing's happening here so it's not like this actually solves a problem you can still have valid code signing certificates issued to malicious entities because the validation process is cannot be perfect because it's again it's the human factor which is where all of our security ultimately fails whether it's humans writing code that has bugs or humans saying you know are you really you know Steve Gibson"

Steve Gibson highlights the decision by the CA/Browser Forum to shorten code signing certificate lifetimes, questioning its necessity and effectiveness. He points out that even with securely stored certificates, malicious actors can still obtain them and that this change does not prevent the issuance of valid certificates to malicious entities, suggesting the validation process remains imperfect due to the human factor.

"The problem is this is still an imperfect system bugs in signed software are no less prevalent than in unsigned software so signing offers no guarantee about software quality and bad guys are just as able to exploit bugs in signed as in unsigned software but it is certainly worthwhile to require a signature rather than not if nothing else something somewhere is known by someone about the signer of the software there's at least some modicum of accountability and traceability so I can see that you know that it's not a bad thing and if a piece of signed software is discovered to be malicious then its signing certificate can be immediately blacklisted and is so that nothing else signed by that presumably malicious certificate will be trusted"

Steve Gibson acknowledges that code signing, while imperfect, offers a degree of accountability and traceability. He explains that while it does not guarantee software quality or prevent bugs, it is still valuable because it allows for the blacklisting of malicious certificates if discovered, thereby preventing further trust in software signed by that certificate.

"The critical flaw is that once mongodb has finished decompressing it never checks the actual resulting size of the newly decompressed payload it trusts the data the user provided using that as the actual size of the payload now I need to stop here to hover over that phrase a bit longer that phrase being it trusts the data the user provided if we were to produce a list of the root causes behind many of the worst flaws that we that that have been found in software trusting user provided input would definitely be right up there near the top if not perhaps in first place since even buffer overflows typically result from the similar mistake of trusting and using something that a malicious user deliberately provided in this case we have a deliberate buffer underflow that results entirely from trusting input from the user"

Steve Gibson identifies the core of the "MongoBleed" vulnerability as the database's failure to validate the actual size of decompressed data against the claimed size. He emphasizes that this trust in user-provided input is a fundamental flaw, a recurring root cause in many software vulnerabilities, leading to a buffer underflow where the system does not properly check the decompressed payload's size.

"The result of the bug is that multiple megabytes of the server's raw internal data can be exfiltrated to the attacker this data might and often does contain clear text passwords and credentials session tokens api keys customer data database configurations system info docker paths and client ip addresses and so on in short all of the internal operations of the server that would otherwise never be made available to anyone whether they had authenticated and were legitimate user or not"

Steve Gibson explains the direct consequence of the MongoBleed vulnerability, which is the exfiltration of sensitive server data. He details that this leaked information can include plain text passwords, API keys, customer data, and configuration details, effectively exposing internal server operations that should remain private, regardless of user authentication status.

"My question is why was even a single instance of mongodb publicly exposed i'm sitting here right now as i talk to leo and our audience in southern california from my location here i have access to any and all of those 87 000 some instances of mongodb why why do i have access why can i send out a tcp syn packet to port 27017 of any to any of those 87 000 ips and promptly receive a tcp syn ack packet inviting me to complete the tcp handshake connection i have no need to ever do so whoever runs that mongodb instance certainly doesn't want or expect me sitting here in southern california to be able to connect to their database server but i can why by now i hope that everyone in this podcast's audience understands not only that this is wrong but just how wrong it is"

Steve Gibson expresses strong disapproval of publicly exposing MongoDB instances, questioning the rationale behind such configurations. He highlights his ability to connect to thousands of these servers from his location, emphasizing that this access is unnecessary and unintended, underscoring the severity of the security lapse.