Slashdot Mirror
Why Sharing Ransomware Code For Educational Purposes Is Asking For Trouble (betanews.com)
Mark Wilson writes: Trend Micro may still be smarting from the revelation that there was a serious vulnerability in its Password Manager tool, but today the security company warns of the dangers of sharing ransomware source code. The company says that those who discover vulnerabilities need to think carefully about sharing details of their findings with the wider public as there is great potential for this information to be misused, even if it is released for educational purposes. It says that 'even with the best intentions, improper disclosure of sensitive information can lead to complicated, and sometimes even troublesome scenarios'. The warning may seem like an exercise in stating the bleeding obvious, but it does serve as an important reminder of how the vulnerability disclosure process should work.
Most people that find vulnerabilities want to tell the manufacturer. But after a long history of being ignored or even being threatened, many have reverted to giving the corporations responsible a fixed, short time to fix things, because otherwise nothing happens. Giving time more time just makes them drag their feet, because fixing vulnerabilities costs money. Those complaining here are at the very root of the problem. I should also point out that this corporate fuck-up has been going on for a few decades now.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Martin Roesler, Trend Micro Senior Director for Threat Research says...
We need to share knowledge that creates understanding about potential damage, but not the ability to create it. We need to share knowledge about 'who exploits work', but not 'how to make use of them'. We need to share knowledge 'how malware works', but sharing 'sample code' is not needed for that.
i wouldn't consider him a reliable source considering he allowed them to write a password manager in javascript.
Anons need not reply. Questions end with a question mark.
Well, it seems to me that two things are likely true:
1) Making malware code public helps malware programmers (current and aspiring) write better malware programs.
2) Making malware code public helps anti-malware programmers (current and aspiring) write better anti-malware programs.
Who benefits more? I honestly don't know. However, my bias is towards openness over secrecy, and I think it needs to demonstrated that the risks of making malware code public outweigh any potential benefits.
Momentarily, the need for the construction of new light will no longer exist.
If a company is (arguably) already treating security reasonably seriously, then spreading details on how to hurt their customers does not achieve anything.
That kind of assumes there aren't malicious people already exploiting the bug.
Sometimes it's better to let people know so they can defend themselves: either by closing a port, changing a configuration, turning off a service, fixing the bugs themselves and recompiling, or switching to another software system.
Of course, corporations don't like the last two options, but being able to recompile is a very real benefit of open source software.
"First they came for the slanderers and i said nothing."
No, selling stuff is the goal of many places that among other things care very little or not at all about security. Your bit about "If a company is (arguably) already treating security reasonably seriously" is very much the exception instead of the rule. I've reported gaping security holes that were left open for years and they were not taken seriously because nobody on the outside had been caught exploiting them - and that was on a cash handling system FFS!
I don't condone those making the bugs public but I can see why they do it. Reporting a serious security problem to some places can both land the reporter in deep shit and still result in nothing being done to fix the actual problem. Management in such places sees taking action against the reporter as the complete solution to the problem. Their reaction to an open farm gate would be to shoot each cow on the way out instead of shutting the gate.
Many of open source projects I'm involved in use a responsible disclosure model. It has worked very well, getting most users patched a few days or a few hours BEFORE the bad guys knew how to exploit it, rather than soon AFTER they got exploited. I'll use as two examples issues I found in Wordpress and PowerDNS (used by wikipedia and other large sites).
I found an issue with Wordpress and opened a security ticket describing the issue and my proposal for a solution. As a security ticket, it was initially visible only to the security team. Over the next 24 hours or so, it was discussed and consensus was developed regarding the right solution. Over the next 24 hours, it was tested and (quietly) pushed to the repository. On the third day, everyone who had Wordpress set to automatically update got the fix, and admins with many, many Wordpress users such as Wordpress.com were notified. So maybe 80%-90% of the Wordpress users had the update on day three. On day 4, the information became public - 24 AFTER the updates had already happened.
Note it took a couple of days between the time the patch was ready and the time most users were protected. Had we released the patch and the information together, that would have been a day or two that the bad guys could have infected servers with persistent malware.
Power DNS was similar, except distros needed time to compile and package the fixed version. So the issue was discussed privately, and the fix tested. Had the vulnerability been public, someone would probably have used it to take down Wikipedia, so Wikipedia was notified of the fix along with a few other very large sites. While Wikipedia was patching, Redhat, Debian, and the other distros were preparing updated packages for their users. This was roughly day three. On the morning of day #4, Debian mailed their users to let them know that a security fix was available and that had information about the vulnerability- AFTER the update was already available from Debian's servers, which was a day or two after the source patch was privately distributed to the appropriately people.
Something else happened that day too. About an hour after the Debian security alert email went out, I had a job interview. When I told the interviewer I worked mostly with Red Hat systems, he seemed disappointed. The conversation continuedg
"We use Debian. Do you know anything about Debian?", he asked. ..." :)
I replied "did you see that Debian security alert about an hour ago?"
"Yeah, this one right here?" he said as he opened the email.
Looking at the first line of the email, he saw it said "Ray Morris discovered a vulnerability
Suddenly he seemed less concerned about my knowledge of Debian.