Rapid7 throws JetBrains under the bus for 'uncoordinated vulnerability disclosure' Security shop Rapid7 is criticizing JetBrains for flouting its policy against silent patching regarding fixes for two fresh vulnerabilities in the TeamCity CI/CD server. Rapid7 says it reported the two TeamCity vulnerabilities in mid-February, claiming JetBrains soon after suggested releasing patches for the flaws before …
"its policy against silently patching vulnerabilities, which stipulates that if companies violate that policy, Rapid7 will itself release the full details of the vulnerability, including enough information to allow people to develop exploits, within 24 hours"
I absolutely accept that patching without disclosure is bad news, but to insist that disclosure precedes patching merely contributes to global vulnerability. It should be sufficient to disclose immediately after release of a patch -- to give customers the opportunity to protect themselves properly.
I detect many cases of an increasing detachment between vulnerability investigators and the realities of ensuring security, ranging from (let's face it -- threatening) stipulations of this kind to disclosure of obscure attack vectors with recommendations that could interfere disproportionately with legitimate operations (such as a recent suggestion that thermal imaging cameras should be prevented from viewing keypads because they might be used to crack entry codes, thereby also preventing their use in, for example, forensic examination).
But it's all the more problematic when the discoverer of a vulnerability attempts to place a vendor over a barrel. I know there's an (often valid) argument that vendors are negligent and unresponsive when alerted, but I'm quite convinced that threats and "protection" tactics are not the answer -- they perpetuate an antagonistic culture that exacerbates any non-cooperation.
I believe Rapid7 didn't try to dictate anything but were miffed that JetBrains didn't even attempt to coordinate when to disclose that information with them. If JetBrains doesn't bother to talk to Rapid7 about timelines there's not much room for them to complain any details were released to early.
Yes, these are the good guys. Their policy on silent patching is the industry norm.
Their policy isn't "release details of the vulnerability prior to a patch being available" it's "Don't patch without publicly, LOUDLY disclosing the vulnerability and how it functions" the reason for this is actually really straightforward. The only people who reverse engineer patches on the regular are sophisticated attackers. A silent patch does not hide a vulnerability from attackers, it only hides vulnerabilities from people with other things to do: pen testers, IT personnel who are responsible for scheduling and prioritizing patches on their networks, threat detection developers, adaptive threat mitigation services, news agencies and exploit disclosure outlets that are responsible for helping to timely inform all the previous individuals. Silent patches lead to longer exploit windows overall and allow attackers to establish footholds that they can leverage in future to increase their compromise of the exploited networks, even long after the patch for the original exploit has been applied. The IT personnel none the wiser as to the need to be on the lookout.
This is why threat researchers across the industry have adopted the policies they have. When you patch an issue, disclose that issue in full technical detail. That helps all the good guys to do their jobs, while giving the bad guys no more information than they would have obtained on their own in a few hours.
An easily understood "here's how the vulnerability works" gives everyone (bad guys included) enough information to use that vulnerability during the time it takes for the patch to be applied everywhere.
Patches have never been deployed instantly, so those "few hours (days/weeks)" they have are definitely a problem.
I'm not sold on the idea of "if you patch silently, we'll tell everyone what you patched, and how it was vulnerable" being even slightly a good idea.
Silent patches mean that the bad guys know that patch fixes a vulnerability, while the good guys don't. That leads to IT teams leaving that patch at a lower priority, possibly pushing it to the next maintenance window.
Threat detection services use the technical details to implement detection parameters/ canaries to warn clients they have been compromised, how that occured, and what needs to be done to shore up that breach.
Pen testers use those technical details to run exploits for those vulnerabilities on their client's tech stacks, thereby insuring neither the client nor one of their software vendors is still vulnerable.
Threat mitigation services use those technical details to help build the algorithms that detect exploit usage and automatically quarantine parts of the network if necessary to protect from further exploitation.
Threat monitors will use the technical details to demonstrate exploits against the system(s) in question in an ongoing manner to guarantee that the exploit is not reintroduced at some point.
Silent patches are good for the bad guys and no one else. There are even cases where a company seeking to avoid the bad press, silently patched an exploitable issue, only for there to later be a regression where the exploit was reintroduced to the codebase because the company didn't even keep an internal log or instrument a test case to cover the exploit.
I am a Kaspersky fan, it is one of if not the best security tools out there. I had to remove them just before putin attacked Ukraine due to putin killing people that don't do what he tells them. If he took the staff and said do this or I will kill you and your family - everyone knows he has and will.
So far Kaspersky has been 'allowed' to not be involved in the war, and the product and company still has it's integrity (less being associated with putin by being in the same country)
I hope they out last putin (please someone end the madman) with their reputation in tact. If so I will GLADLY rip MS defender from our systems and put K back in. If they do just one dirty dead it will kill the company permanently.
But until then,,, I wish them luck.
From https://www.forbes.com/sites/thomasbrewster/2021/01/07/meet-the-super-rich-czech-tech-company---and-its-russian-ceo--denying-links-to-the-huge-solarwinds-hack/?sh=74af8ec74eb9:
JetBrains has some links back to Russia. Shafirov (previous CEO) is Russian, as are its three cofounders: Sergey Dmitriev, Eugene Belyaev and Valentin Kipiatkov. Three of its six research and development centers are also based in Russia, alongside its bases in Germany, the Netherlands, the U.S. and the Czech Republic.
Ah ha! Thank you! Look, actual information backing up an opinion!!
I’m not worried about R&D in Russia, and the owners funneling money home is no issue, the question is whether the code base is at risk.
The Russian secret service has murdered multiple people in the UK in recent years, so I would say the families of UK company employees could be at as much risk of threats as any Russian individual these days! Nonetheless, point accepted and thanks for answering for the anon
As I understand, they no longer have ties to Russia - all the devs relocated elsewhere long ago, and their St Petersburg offices have also been closed. This Reddit thread from last year details some of this and contains a link to their blog post giving full disclosure: https://www.reddit.com/r/dotnet/comments/yt1bm2/jetbrains_and_russia/
Where do you think the malware farms are operating from? There are literally rows of businesses and office blocks outside Moscow with call centres operating 'em.
It's not just a case of where there's smoke, there's fire. This is literally a blazing inferno in full view of everyone.
Is it worth it? Sacking off anything on important systems with origins that can be linked to the Rodina? Probably, yes. Unless you have the source code and compile it yourself after careful inspection you don't know what they put in there.
I use JetBrains IntelliJ for my Java/React stuff today and I noticed it's got AI for an additional fee. There was an El Reg article a few weeks ago about it that was critical of the inclusion.
I mention that because, as I peruse the Reg's homepage, I notice a shitload of AI-generated images instead of the standard stock images over articles including this one. I assume it's cheaper to use AI, but the images are all strange. (The URL still shows shutterstock - https://regmedia.co.uk/2024/03/05/shutterstock_screen.jpg)
Icon because murderbots are less unsettling.
I'm for full disclosure but I do find Rapid7's policy aggressive. The standard policy Rapid7 follows is to file a CVE after 15 days if they don't hear back from the vendor; the CVEs filed with CERT/CC are private for 45 days (if the filer doesn't choose to make it public earlier..) So basically you'd have 60 days to get a patch out to customers then the CVE is public anyway, feel free to publish exploit^H^H^H^H^H^H proof of concept code and all that. That part seems fine! But...
Rapid7's argument is valid, when a company is putting out security patches it's pretty easy to take a peak at them and it points you straight to the exploit. There was a big problem in the past with companies just blending in the security fixes with product updates, people were frequently running vulnerable software because they're like "I don't need these new features" and there was no disclosure of the security content of the updates. Truly silent patches.
And I even think this "24 hours disclosure after a hidden patch" is fine for companies that truly do silent patches -- they are typically trying to hide security fixes in with general updates for their software, "sweep it all under the rug." Since people aren't told there's a security update, they had no urgency to update. If the software has an automatic updater most people's copies may be updated within that 24 hours anyway, otherwise many people may never update it. So in the case of a true hidden patch, disclosure after 24 hours versus a month or 45 days would likely make little difference.
But it seems like a pretty perverse interpretation of their own rule on Rapid7's part to consider this a silent patch... After all, JetBrains filed a CVE (which would automatically disclose in 45 days), created a patch that was specifically described as a security patch, and then E-Mailed their customers to tell them "This newer JetBrains fixes important security holes, please install it, but here's a patch for your current version". I don't know how that is a silent patch, and given this needs some manual intervention to install (it's not going to auto-update itself..) it seems perfectly reasonable to at least give people a few days (like a week maybe if not that full 45 days) rather than 24 hours to get those patches installed before full disclosure time.
Hitherto, my only knowledge of JetBrains has been its rather excellent Mono font, available from them and Google Fonts, and undoubtedly elsewhere.
It includes nearly 140 code ligatures, 8 weights each with italics, and support for 145 languages - whether you need these features or not!
Ugh. I loathe, loathe, loathe JetBrains Mono and its accurséd ligatures. We use Upsource for code reviews on one of my teams, and I had to disable font downloads to get rid of all the damned ligatures. (Upsource lets you configure a different font for some elements, but not all.) Of course, disabling font downloads is a good idea anyway, because, hey, stupid additional attack surface.
If Kernighan and Ritchie had wanted us to use ligatures in C, they ... well, they would have been wrong. It's a terrible idea.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
