VLC 3.0.7 and security (opens in new tab)

The libcurl maintainer got/gets emails[1] asking for technical support on people's cars because they likely stumbled across his email address in the mandatory license text.

1. https://daniel.haxx.se/blog/2016/11/14/i-have-toyota-corola/

And why do they feel it's appropriate to ask for help there? This would be like going to a talk from a presidential candidate about fuel economy, and raising your hand and saying "My car doesn't start, can you help me?"

Covert spam?

1) Spammer uses a bot to post harmless automated comments

2) Waits for a while, than looks which of his comments ranks higher in Google

3) Edits some of top-ranked comments to include usual viagra ads with hyperlinks to promoted websites

This sort of thing was so much more common (and worse) in the late 90s/early 2000s.

You couldn't write a blog post about some security finding or integration achievement without it attracting a slew of comments from clueless outsourced contractors begging you to teach them how to build or deploy a related enterprise-scale solution.

(I'm the author of the blog)

> Is this really valid?

Yes/No. The issue is more about categorizing between low, medium, high and critical security issues, because this impact the bounties values.

So, we have to define some guidelines on which is high or medium, because this is the most difficult part to differentiate. OOB reads gets medium, while OOB write gets high. Buffer overflows get high, while Null-deref gets medium.

If you try hard enough, those are probably exploitable, but maybe, we're not sure. While the OOB writes are exploitable, so this is more important, so it gets high.

Of course, it is important to fix everything, but we need to be fair, notably when it is not our money.

Cannot really be said in a general way. With a lot of effort probably all of those could lead to more serious things, but not easily in a platform and setup agnostic way, i.e., you probably need time and be able to try multiple times to get you a realistic chance. If it's not possible to try multiple times (e.g., your try crashes or runs into some other protection mechanism (no-execute flag on page set, return address validation, ...) then there's, again depending on the specifics of the bug and it's context, a very slim chance to achieve a (arbitrary) remote code execution, or something similar serious, realistically.

Also, for side channels you often need to be able to run code on the host, in some way, at which point it's probably not really interesting to exploit through VLC (as it runs normally as non-root/non-admin user anyway). Else, you'd need to be able to get some VLC responses which have a code-address related measurable characteristic (normally time-deltas), not sure if VLC can be forced to leak such infos from remote.

Determining whether bugs are exploitable is hard: usually, the answer tends to be “yes, if you try hard enough”.

I filed a bug report about something just like that many years ago (hanging in a CPU intensive loop if you remove all the files in the looping playlist out form under it, i.e. a disk drive goes offline or USB stick is unplugged), and he brushed it off and dismissed my bug report, telling me simply not to do that.

And I also took the time to file several other very detailed bug reports against the Video Effects / Magnification Zoom user interface, which is not only ugly and poorly designed from an ergonomic perspective, but actually drawn into the video at video resolution instead of being drawn in an overlay at full screen resolution, so it gets rotated and is unusable when you combine it with Video Effects / Transform / Rotate, because it fails to transform the mouse events the same as the video and user interface. He brushed that one off as working as designed, too. It's still just the same as it was many years ago when I filed that bug report.

I'm serious: Give it a try, you'll fall out of your seat laughing at how terrible it is! Check out the lowres pixelated font it uses to draw "VLC ZOOM HIDE" between the thumbnail and the bizarre curved zoom scale wedge! The mouse target area of the zoom wedge actually diminishes in size with the width of the wedge, until the minimum zoom target area is only one video pixel wide at the bottom, so it's almost impossible to click. (And it's totally impossible to click anywhere when the video is rotated or flipped, since the target area isn't correspondingly transformed.)

Yes, I know the drill: It's free software, so I should just download the source code, read it, figure out the problem, fix it myself, and post a pull request. But I don't feel spending my time doing that after the author of VLC won't even admit there's a problem.

Excellent point: yes, we fixed (actually worked-around) that bug in this release.

Sorry about forgetting about it: I cared more about the FOSSA project here, and forgot about this.

That’s not a security bug, though?

VLC have a past with "security-asshole" that could explains why JB seems tired with some members of the infosec community in general. From what I've read from the past controversies, each time a security issue arises in VLC the team is attacked by an angry mob of infosecs.

This blog post closing remarks summarize the recurring issue well: https://www.beauzee.fr/2017/07/04/videolan-and-https/

Yeah, that'd really put me off reporting anything.

All videolan files are GPG-signed and have several hashes (md5+sha1+sha256)

This seems like it would incentivize simply selling to grey markets.

There's a wide variety in the quality of responses to bug reports too.

Last year I stumbled across a bug which could result in a leak of personal data (specifically, private messages). So I did the good-samaritan thing and reported it, opening with "I don't want a bug bounty for this" (it was a pretty trivial bug, just a high impact one).

What I got back was a wall-of-text missive about how it wasn't on the OWASP TOP10, wasn't eligible for a bug bounty anyway, and finished with a personal attack. I didn't even reply to it.

I haven't bothered submitting anything else, not on Hackerone, not anywhere.

(author of the blogpost here)

> It's not clear whether the asshole in question is being dogmatic about some ninety-day disclosure-to-publication deadline or whether they're maybe being rude about the project having security bugs.

Being dogmatic with 90days disclosure, would get you a "hardline security reporter", but not an "asshole".

Notably, because there has been no reporter that refused to extend by a reasonable amount of days, for us. "Hey, can we get 120 days, because we got other bugfixes and we want to do all of them together".

No, we're talking about actual assholery here:

- requesting answer and reproducibility in 24hours, and sending 10 mails in the mean time;

- sending the same issues more than 10 times, because the stacktrace he has is slightly different, but refusing to listen when told that this was the same issue, and therefore only one bounty;

- refusing to read the guidelines, and refusing to test the good version, and then insulting us;

- agressivity, or insults, to the point where the HackerOne team had to intervene several times;

- plugging the output of his fuzzer to HackerOne without checking if it actually crashes or if it is a different bug;

- submitting the same bug to a different program (Google Android Apps) to get 2 times the bounty, while the bug DID NOT apply on Android, but he did not even check;

- a few others that I forgot.

So yeah, this is not about dogmatic or hardliners: we know how to deal with those in the open source communities.