Hacker News Reader

Hacker News

Comment by _jomo | Hacker News Reader

Full thread

_jomo

These are the VLC commits adressing the issue:

https://github.com/videolan/vlc/search?utf8=%E2%9C%93&q=subt...

View on HN

As usual, the common set of friends we already know since the 80's:

> Fix potential heap buffer overflow

> Fix potential out of bound read

> Fix invalid double increment.

i've never seen a double increment exploited before- it's undefined behavior, but what is the typical route against that?

Use a memory safe language that doesn't require direct pointer manipulation to access string and memory buffers, with an optimizer able to elide bounds checking if proven safe to do so.

The double increment itself isn't undefined behavior. Note that the two increments were separated with a semicolon, making them separate statements. It's equivalent to pzs_text += 2;.

The exploit would presumably involve structuring your data so that the excess increment skips over a terminator of some sort. If it's scanning until it hits a zero byte, and you get it to skip over the zero byte, then you have a buffer overflow.

Ahh, that does make sense, i didn't see that.

I don't seem to find a way to update VLC to 2.2.5 on Ubuntu (or Debian, or Mint for the matter). I understand Canonical does not provide updates in the repos - but the VideoLAN website's download URL for Ubuntu is just "apt://vlc" - it would be nice to be able to download one or more .deb's too.

Do we have to build it from source?

You can use snaps, but they are currently broken due to build issues.

Damn, building from source is nigh impossible. Given the sheer amount of plugin libraries that need to be installed. - https://wiki.videolan.org/Contrib_Status/

Holy crap, that code doesn't look good. I predict we will see more exploits for this project.

Maybe we should stop random people from contributing to complex C projects?

That was my hope when C was just gaining market share outside UNIX, and here we stand now.

"random people"? You mean there's some select group we know of that doesn't ever write bugs? (DJB doesn't make a group)

The main VLC developer is an amazing programmer. But if he uses his time to shave cycles off some SIMD decoding algorithm then boring things like file processing is done by random jr. developer.

The problem is that boring stuff can also be very security sensitive.

You are more than welcome to contribute and since you have a very strong opinion it seems you know your stuff, so go for it, nobody is charging a dime to work there in any case.

> you have a very strong opinion it

Yes I do, this is internet after all!

> seems you know your stuff,

Now you lost me :)

Look at FFmpeg and all the multimedia libraries and you will be horrified.

I thought they cleaned up after the last round of exploits?

hahah :)

I wish :)

vlc has a bug and yet you talk shit about well developed and fuzzed by google projects. thats why vlc will never be better than mpv.

FFmpeg, VLC, MPlayer, libdvd*, libxvid, x264, libflac, libvorbis and all the other have multimedia library codebases started in the late 90s/early 2000. Noone cared much about security at that times.

All those projects are under-funded, done by volunteers, on countless platforms, doing very low-level stuff, and supporting many formats.

This has nothing to do with one project or another.

thats sad to hear, I didn't know volunteers did so much

Wouldn't go that far from reading a single commit, but to anyone looking to pick up tips from a well-known respected C codebase: don't ever write

    (*(psz_text + 1 ) ) == '~'

when you can instead write

    psz_text[1] == '~'

Fewer tokens means less overhead for the human reader, and that asterisk-and-add pattern is exactly what the bracket array indexing operator does, so why not use it? This is one of my many C pet peeves, heh.

Also on a more personal note, if you're going to be putting things inside parentheses with whitespace, make it symmetrical.

Reply on news.ycombinator.com