VLC adaptive HTTP User-Agent injection vulnerability

Rémi Denis-Courmont

VLC 3.0.6 suffers from an HTTP request injection vulnerability.

June 10, 2019 08:00 PM

Hong Kong Open Source Conference 2019

Rémi Denis-Courmont

I will be giving a talk on VLC media player in cooperation with the VideoLAN foundation at the upcoming Hong Kong Open Source Conference on 14-15 June 2016. Follow the link to sign up. See you there.

June 09, 2019 07:00 PM

VLC 3.0.7 and security

Jean-Baptiste Kempf

VLC 3.0.7 release and EU-FOSSA

We just released VLC 3.0.7, a minor update of VLC branch 3.0.x. This release is a bit special, because it has more security issues fixed than any other version of VLC.

This high number of security issues is due to the sponsoring of a bug bounty program funded by the European Commission, during the FOSSA program.

Severity

According to our scale, we have had 33 valid security issues fixed thanks to this program:

• 2 high security issues, (only one was present in 3.0.x),
• 21 medium security issues,
• 10 low security issues.

The 2 more important issues are an Out-of-Bound Write and a Stack Buffer Overflow.

the Out-of-Bound Write is not in the VLC codebase, but in a dependency of VLC, the faad2 library, unmaintained, unfortunately.

the Stack Buffer Overflow is a VLC 4.0-only issue in the new RIST module, and is therefore not impacting actual release of VLC.

The medium security issues are mostly out-of-band reads, heap overflows, NULL-dereference and use-after-free security issues. Those issues should not be exploitable with ASLR, but are important anyway, because they can crash VLC.

The low security issues are mostly integer overflow, division by zero, and other out-of-band reads with no actual impact. Those issues are not exploitable.

The best hacker on the program was https://hackerone.com/ele7enxxh.

Opinion about bug bounties

What follows is my personal opinion about those bug bounties programs, and is not VideoLAN's point-of-view.

Usefulness

If you've listened to some of my talks or spoke to me (I'm sorry for you), you know I'm a bit critic of those programs, because they give money to find the issues, not to fix them.

What about you give money to VLC instead of random hackers?

Well, security is important, so this is cool for our users, but still this is a mixed bag, for me.

So, in order to mitigate that, we gave large extra-bonuses for fixes provided at the same time as issues were found, to improve this problem.

Hackers

During this program, we've had a lot of different hackers, from the best to the worst technically: so many script-kiddies, and people telling us that the VLC source code was visible... but also people who had deep understanding of C, of the stack and of memory issues.

But I would like to focus a bit more on the type of reporter we've seen.
We've had people ranging from the usual security-asshole to some of the nicest guys ever, who cared deeply to help us. And when working with the nicest people, they often send patches to fix too.
At the opposite, some reporters were more than distasteful, insulting, impatient, trying to get 2 times the bounty for the same bug, or even reporting the issues to other programs (Android one) to get more money.

The result of that, is that when you don't know how much to award for a security issue (is it medium or low?), you decide on the niceness of the reporter

Thanks

In the end, I'd like to thank the European Commission, Julia Reda, the nice hackers and the people from the team who fixed all those bugs!

June 07, 2019 07:23 AM

dav1d 0.3.0 release: even faster!

Jean-Baptiste Kempf

tl;dr: dav1d another fast release

If you want a quick summary of this post, about our AV1 decoder:

• dav1d is still ready for production, and getting used more,
• dav1d has a speed gain of 12% on ARM64 mobile CPUs,
• a gain of 15%-25% on SSSE3 processors
• and even a 5% gain on AVX-2 processors, which was already quite fast.

Read the following for more details...

A few reminders about dav1d

If you follow this blog, you should know everything about dav1d.

AV1 is a new video codec by the Alliance for Open Media, composed of most of the important Web companies (Google, Facebook, Netflix, Amazon, Microsoft, Mozilla...). AV1 has the potential to be up to 20% better than the HEVC codec, but the patents license is totally free, while HEVC patents licenses are insanely high and very confusing.

The VideoLAN, VLC and FFmpeg communities have started to work on a new decoder, sponsored by the Alliance for Open Media, in order to create the reference optimized decoder for AV1.

Third major Release

We just released the third version of dav1d, called 0.3.0 Sailfish.
The decoder is ready and being now largely used on all platforms, with excellent performance.

The focus for the first release was for AVX-2 processors, with up to 5x speedups compared to the reference decoder.

The second release was focusing on the other desktop CPU, SSSE3 and on mobile phones (2 to 4x faster) , and a lot more stability.

This third release continues to increase the ARM and SSSE3 speed, with more optimizations, as announced, and we get between 12 and 25% speed increases on those CPUs, depending on the samples.
However, more surprisingly, we got a speedup on AVX-2 CPU, by optimizing the MSAC (entropy decoding), while we did not find a good solution in the past. This brings 4-5% speed improvements, which is quite huge, knowing the maturity of the AVX-2 code.

Results

This are the gains we got for SSSE3 compared to the previous release:

And this is where we are, on desktop platforms, compared to aomdec:

As you can see, we're now getting consistently 2.5 to 4 times faster on SSSE3, 2 to 5 times faster on AVX-2 compared to aomdec.

On mobiles devices, we're now also getting 3 to 4 times faster with ARM64 CPU than aomdec. I don't have a fancy graph, but you can see results here.

What's next?

What's next is more complex to foretell: there are still some optimizations to do on SSSE3 and ARM64, but they are getting less important, so the speedups might not be as impressive as those shown today. We might improve AVX-2 still, but we're talking about a few percents, it's going to be hard to get more.

We're also going to toy with compute-shaders for decoding faster, but it's very hard to know if that's going to give a speed-up at all.

Keep in touch, and you'll see!

May 03, 2019 04:48 AM

Announcing VLC 3.1 release!

Geoffrey Métais

This is the first feature update in the VLC 3 cycle. It brings back Android auto and improves support of Oreo and Pie. This version only supports Android 4.2 and newer. This allows us to use up-to-date SDK and restore some features like Android Auto!

After 3.0 release, we could upgrade SDK and start a big refactoring. VLC now implements Android Arch Components, which helped us to drastically improve the application.
We basically rewrote the middle layer of VLC-Android from scratch, and made app architecture cleaner and safer. It results in a more stable app and more code shared between mobile and TV UIs.

Release cycles will become shorter now, v3.2 should be released before the summer. It will be easier for us to publish it and VLC will keep up to date.

Onboarding

Scanning your whole device storage is no longer mandatory. We have the will to keep VLC application lightweight, and some of you only use it as a player.
We heard that, and now you can choose between the classic big scanning, a folders selection or no medialibrary at all!
VLC still provides a file and network browser, if that’s enough for you.

Launcher shortcuts

On Android 7.1 and above, you can resume the last playlist you were listening to without even opening VLC 😌
Just long press on VLC icon on your device and shortcuts will pop up.

They are only static shortcuts for now, we plan to make it customizable.

Group videos by folders

There is a new option in Settings→Video→Group videos, videos can now be grouped by folder. It’s a convenient way to present you your collection.
That was a much asked feature.

Android Auto is back!

Because of Android 2 support, VLC-Android 3.0 was stuck on an old SDK and Android Auto had become too buggy.
It is now restored, enjoy your music with VLC on the road again!

Large media libraries

Among the huge refactoring we did on VLC-Android, we implementend pagination for audio collection. This offers a better support of large collections. Collections with like 10GB of MP3s no longer overflow VLC, it should handle the task now.

VLC won’t load all tracks at once anymore, it loads ‘pages’ of media and fills the list on the fly.

Home screen channel

You can now see last added videos from Android TV launcher (only for Android 8 and above), and even preview one when you focus on it!

File browser

Browser gains some neat additions.

First of all, OTG devices are now supported.

You also can now set any folder as favorite (not only network folders), so you will find them directly at root level of browser

To ease navigation, a breadcrumb is now displayed to show you where you are.

Other new goodies

Application:

• Refactored subtitles downloader
• Sorting preferences are now saved
• A-B repeat
• Manual orientation lock in video player
• Podcast detection has been improved
• Bottomsheet style for context menus
• Playback notification is now persistent, even when app is closed by Android

TV:

• Sort media
• group videos by name

VLC:

• AV1 software decoding.
• SMB 2/3

For any feedback, you are welcome to join the VLC-Android community page!

April 03, 2019 12:00 AM

dav1d shifts up a gear : 0.2 is out!

Jean-Baptiste Kempf

tl;dr: dav1d has its second release

If you want a quick summary of this post, about our AV1 decoder:

• dav1d is really ready for production,
• dav1d has impressive benchmarks on ARM devices,
• dav1d is now fast on 32-bit desktop processors (SSSE3).

Read the following for more details...

A few reminders about dav1d

If you follow this blog, you should know everything about dav1d.

AV1 is a new video codec by the Alliance for Open Media, composed of most of the important Web companies (Google, Facebook, Netflix, Amazon, Microsoft, Mozilla...). AV1 has the potential to be up to 20% better than the HEVC codec, but the patents license is totally free, while HEVC patents licenses are insanely high and very confusing.

The VideoLAN, VLC and FFmpeg communities have started to work on a new decoder, sponsored by the Alliance for Open Media, in order to create the reference optimized decoder for AV1.

Second Release

Today, we release the second version of dav1d, called 0.2.1, Antelope.
You can now safely use the decoder on all platforms, with excellent performance.

For the first release, we showed impressive benchmarks for AVX-2 processors, with up to 5x speedups compared to the reference decoder.

In this release, the focus has been toward ARM devices (32-bit and 64-bit) and desktop processors that did not support AVX-2.

It is important to know that the ARM and SSSE3 optimizations are not finished yet. You should expect more performance in the future.

ARM devices

For the ARM devices, we've been doing both ARMv7 and ARMv8 acceleration. We've been testing on iOS, Windows and Android to be sure that it works fine on all OSes.

On ARMv8, we achieve between 150% and 200% of the speed of aomdec:

On ARMv7, we achieve up to 400% on the SnapDragon 410:

It's interesting to see that dav1d is faster in ARMv7 mode than the reference decoder in ARMv8 mode on the same machine.

iOS and iPhones

The playback on iOS is quite important, since those are the fastest ARM devices, and quite widespread:

Depending on the samples, we have achieve 1080p at 75fps on Summer sample, and 40fps on more complex samples, like Chimera.

Desktop

For the desktop, we focused on SSSE3 optimizations, because they should cover 98% active of the desktop processors.

We also did optimizations for both 32-bit and 64-bit architectures, and not only 64bits, as we did for AVX-2.

In multi-thread scenarios, we show between 2x and 3x gains compared to aomdec:

Get it

You can get the tarball on our FTP: dav1d 0.2.1.

You can get the code and report issues on our gitlab project.

You can also join the project, or sponsor our work, by contacting me

Conclusion

Dav1d 0.2 is now faster than aomdec on all the 4 important architectures (x86/SSSE3, x64/AVX-2, ARMv7, ARMv8).

The speedups we see goes from x2 and x5, and on ARM devices, we are now approaching 1080p60 in software.

We're going to continue acceleration work on SSSE3 and ARM devices, in the next few releases.

March 13, 2019 09:32 PM

Android runtime permissions in one (suspending) function

Geoffrey Métais

This post offers a basic implementation of a single suspending function managing the runtime permission process.

Runtime permission API

If you are reading this, you should already know this API. It is only composed of requestPermissions method, and its related callback onRequestPermissionsResult. But this is a View-level API, not really convenient.

We still are lucky, this API is accessible from fragments, and that will allow us to make it way easier to use.

Headless Fragment

The trick is to make it a headless fragment, i.e. a fragment without a view. It’s still bound to its activity and can fire dialogs, that’s what we want.

override fun onCreate(savedInstanceState: Bundle?) {
    retainInstance = true
    requestPermissions(arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE), PERMISSION_STORAGE_CODE)
}

// No onCreateView() overriding

override fun onRequestPermissionsResult(requestCode: Int, permissions: Array<String>, grantResults: PermissionResults) {
    when (requestCode) {
        PERMISSION_STORAGE_CODE -> {
            if (grantResults.granted()) {
                deferredGrant.complete(true)
                exit()
                return
            } else if (shouldShowRequestPermissionRationale(...)) {
                // We insist
                return
            }
            deferredGrant.complete(false)
            exit()
        }
    }
}
protected fun exit() {
    retainInstance = false
    activity?.run {
        if (!isFinishing) supportFragmentManager
            .beginTransaction()
            .remove(this@BaseHeadlessFragment)
            .commitAllowingStateLoss()
    }
}

Our runtime permission implementation has become modular, it can be called from any activity just by starting this fragment. That’s a first step!

The permission grant result is handled by deferredGrant.complete(boolean), that’s how we can get a suspend function controlling our fragment.

Deferred behavior

We will now leverage it, and create a single function to launch this permission granting process and get its result.
For this, we use a CompletableDeferred, which is a Deferred like the one returned by the async function, but we can complete it by ourselves once we have our result.

All we have to do is to launch our fragment, prepare a CompletableDeferred and await for it.

Voilà! We have our function:

protected val deferredGrant = CompletableDeferred<Boolean>()

suspend fun awaitGrant() = deferredGrant.await()

companion object {
    suspend fun FragmentActivity.getStoragePermission() : Boolean {
        if (canReadStorage()) return true
        return launchFragment().awaitGrant()
    }
}

Profit

Usage is straghtforward:
From a coroutine, any activity can call getStoragePermission(), and it suspends until user has made its choice.
No callback anymore, and it’s callable from any Activity or Fragment in your app \o/

if (getStoragePermission()) {
    proceed()
} else {
    retreat()
}

While the user is asked for the permission you want for your app, coroutine execution is suspended by getStoragePermission() condition. Then, the relevant branch of this if expression will be executed.

March 09, 2019 12:00 AM

How to use AV1 with open source tools

Jean-Baptiste Kempf

AV1 and muxing

If you follow this blog, you should know everything about AV1.

AV1 is a new video codec by the Alliance for Open Media, composed of most of the important Web companies (Google, Facebook, Netflix, Amazon, Microsoft, Mozilla...) and VideoLAN.

AV1 has the potential to be up to 20% better than the HEVC codec, but the patents' license is totally free, while HEVC patents licenses are insanely high and very confusing.

This is the first time, where the Open community is ahead of the MPEG community, notably because AV1 and Opus are both great codecs.

AV1 has mappings to wrap it inside MP4 or MKV. And other mappings are coming, notably for RTP or TS.

So, of course, the open source community has developed tools to support AV1. This post is about how to use those tools.

Tools

FFmpeg

For FFmpeg, integration with libaom was done for both encoding and decoding (and now also dav1d for decoding).

To encode, it is important to activate the --enable-libaom option at ./configure time.
You can get all the options for encoding by using ffmpeg -h encoder=libaom-av1.

simple encode

To encode any file that is played by ffmpeg, just use the -c:v libaom-av1 option:
ffmpeg -i input.mp4 -c:v libaom-av1 -crf 30 -b:v 0 -strict experimental av1_test.mkv

This works, of course, for the mp4 and mkv output formats.

2-pass encode

For 2-pass encoding, use the usual commands, but with the -c:v libaom-av1:
ffmpeg -i input.mp4 -c:v libaom-av1 -strict experimental -b:v 2M -pass 1 -an -f matroska /dev/null && ffmpeg -i input.mp4 -c:v libaom-av1 -strict experimental -b:v 2M -pass 2 -c:a libopus output.mkv

To know more about AV1 in FFmpeg, please use the help or the official documentation.

GPAC

For GPAC, the integration of libaom was done too, and it is quite simple.

For example, to add an av1 stream inside an MP4, just use MP4Box:
MP4Box -add file.av1 file_av1.mp4

And, you can even prepare those AV1/MP4 files for DASH streaming:
MP4Box -dash 1000 -profile onDemand file_av1.mp4

If you want more details, or try encrypting of those streams, please read the GPAC blog.

GStreamer

Gstreamer made several releases supporting the AV1 plugins.

To play an MP4 AV1 file, just use gst-play-1.0 av1.mp4.

To do a simple encode and mux it in MP4:
gst-launch-1.0 videotestsrc num-buffers=300 ! video/x-raw, framerate=30/1, width=320, height=240 ! av1enc ! mp4mux ! filesink location=av1file.mp4

Or, if you want to transmux from MKV to MP4, or vice-versa:
gst-launch-1.0 filesrc location=av1.mkv ! matroskademux ! mp4mux ! filesink location=av1.mp4 gst-launch-1.0 filesrc location=av1.mp4 ! qtdemux ! matroskamux ! filesink location=av1.mkv

Finally, to transcode to AV1 and mux in MP4:
gst-launch-1.0 uridecodebin uri=file:///home/toto/file.avi ! av1enc ! mp4mux ! location=video-av1.mp4

VLC

Of course, VLC has full decoding integration, with libaom, and with dav1d (starting in 3.0.5, in a few days). This will work on all platforms, starting with desktop releases first.

But VLC 4.0 also has full encoding and muxing, in both MP4 and MKV, in the nightly builds. To use, you can try this:
vlc file.avi --sout "#transcode{vcodec=av01}:std{access=file,mux=mkv,dst='output.mkv'}"

MediaInfo

It's quite important to mention that Mediainfo already supports AV1, since version 18.08.

You can use the GUI, or the CLI: mediainfo av1.mkv.

MKVToolnix

Last, but not least, MKVtoolnix, supports AV1 muxing, since v28.0.0.

Conclusion

Please try those tools, to create and play AV1/OPUS files everywhere.

Also, please report any bug you would find in those tools.

December 19, 2018 02:37 PM