Hacker News Reader

Comment by fulafel | Hacker News Reader

I think the VLC developers come off as pretty defensive in this. They flame the reporter for opening the issue on the issue tracker, but on the issue the reporter says that he got no response from the VLC security contact which he tried first. Then, they dismiss the vulnerability and flame the CVE assigners, because VLC themselves are shipping a distribution with the vuln fixed, even though many Linux distributions and presumably other distributors of VLC remain vunerable - a situation clearly requireing vulnerability coordination and a CVE assignment.

View on HN

Absolutely not:

- the reporter never contacted us, we have a clear process and a bounty program. We checked again, he never did.

- we receive and process all security issues privately: we fixed 31 of them in the last update. And miracly, the other reporters managed to contact us.

- Linux is the smallest OS for VLC.

- An issue on one or two Linux distribution for a OOB-read crash is very very different from "VLC vulnerable on all machines, uninstall now!"

- The CVE number of 9.8 makes no sense. How do you even exploit this crash?

- VLC has DEP and ASLR activated everywhere. How do you execute code with this read issue?

Since this is tarnishing your brand, maybe ask Ubuntu to cease shipping "VLC" if they do such a half-assed job (enough effort to replace integrated libraries with system packages, not enough effort to maintain those packages)?

> maybe ask Ubuntu to cease shipping "VLC"

I want applications to be packaged by my distribution. Updates are up to maintainers (dependencies included), as it has always been.

If MITRE wants to assign a CVE, warning people that they need an updated lib, that's fine. The issue is the trustworthy and handling of CVEs (... plus reporters).

My impression is that VLC did issue an update to use a more recent version of libebml, but Ubuntu/Debian maintainers patched it to use universe’s outdated version (which they don’t even maintain!)

Yes! A glaring example of dependency hell (in Debian words "incompatible library changes with reverse dependencies").

Patching for an older version of libebml is not an issue if that library is not vulnerable (that's why folks use LTS and stable). Want maintainers to know there's a vulnerability? Publish a CVE _for libebml_.

By defensive I don't mean mean everyone else is right, just that there seem to remain a problem that should be addressed (warranting a CVE ID), even if there were hyped headlines in the press and an email communication problem.

IMO it would be better PR to acknowledge the vulnerability and assume good faith on part of the reporter pending indications to the contrary. And maybe skip dismissing the Linux user base like this...

Most / all software has a disclosure policy, send your vulns privately and provide/negotiate a public disclosure date.

Not doing so is an asshole move.

In this case, the solution would be to track down distributions which did not package the software and (privately) disclose to them that the relevant lib needs updating.

>Not doing so is an asshole move.

Dictating how researchers should choose to publish their work product is an asshole move.

If someone chooses to share their work product with you privately, that's very charitable of them. It's not reasonable to expect charity.

Everybody, including researchers, has a duty to publish things responsibly and if necessary, withhold the publication. Despite the economical incentives, the moral responsibility is to research and harden systems, not to publish whatever and build a resume.

You can't just publish information harmful to public and say "well I'm a researcher, so I can do anything I want". Publishing instructions to bypass important security restrictions that people rely on is often harmful and may be even illegal in some countries, for good reason - to protect the people.

Does this universal duty to work for free only concern security research?

>You can't just publish information harmful to public

It’s simply ridiculous to describe full disclosure like that.

I did not say duty to work for free, but duty to observe some restrictions and weighing positive/negative impacts of your publications on society if you choose to work in that domain.

Publicly dropping a bug is still better for the public than keeping it secret. Full disclosure is charity.

I've heard some interesting arguments about publicly dropping 0days to make organisations pull their heads in - Places like Microsoft which historically weren't -great- at security 'deserved' it. I'm not saying that argument is right or wrong, but it was interesting nonetheless.

But dropping a 0day irresponsibly can lead to actual impact - what happens if a good person is persecuted, or executed because of the information you disclosed publicly? What about a hundred. Or a thousand?

by choosing to disclose publicly rather than privately, they’re willfully giving (in their minds) a RCE on every VLC installation to whomever reads the bug logs. I think most people would agree that’s not right.

No, it's called Responsible disclosure. https://security.stackexchange.com/questions/52/how-to-discl...

By not contacting the developer first, you're acting in bad faith. This opens you up to all kinds of legal liabilities, not to mention the social exclusion that will occur.

Nonsense. “Responsible disclosure” is a term coined by vendors to shame researchers who don’t play ball.

There’s no implicit “bad faith” in full disclosure or even the sale of weaponized 0day exploits.

Oh this trope again. I am no vendor and I fully support the idea that security researchers coordinate their publication activities with affected parties.

Great, me too. But I also fully support the idea that people should be allowed to do whatever the fuck they want with their work product. (within the limits of the law, of course)

Charity is nice, but I’m not going to insist that you donate your whole paycheck!

> I also fully support the idea that people should be allowed to do whatever the fuck they want with their work product. (within the limits of the law, of course)

Do you want ham-fisted regulations? Because that's how you get ham-fisted regulations.

Lawmakers analogize. All it takes is for some bright representative to think that "vulnerability disclosures" are more akin to "burglary tools" than to public service announcements to justify criminalizing third-party security research (or the resulting disclosures).

> All it takes is for some bright representative to think that "vulnerability disclosures" are more akin to "burglary tools" than to public service announcements

It doesn't even take that much - throwing around terms like "bad faith" and "legal liabilities" suffices to create a hostile legal regime through common law torts. I'm okay with socially condemning unilateral disclosure as a likely assholeish thing to do, as long as we acknowledge that being an asshole is perfectly legal.

I'm admittedly not up to speed on this particular soap opera, but it seems like the real blameful parties here are Gizmodo et al - scraping the bottom of the barrel for raw technical tidbits, and then escalating them into sensationalist "news" narrative rather than performing any sort of responsible interpretation.

Reply on news.ycombinator.com