4 ms·

Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems. WebRTC security flaws are responsible for a lot of compromises. It's one of the fir

Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems. WebRTC security flaws are responsible for a lot of compromises. It's one of the first things I disable after installing a browser

Sean-Der 1y ago
What security flaws? This implementation is very small. I feel 100% confident we are giving users the best thing possible.
- globie 1y ago
  I assume autoexec is referring to the plethora of WebRTC vulnerabilities which have affected browsers, messengers, and any other software which implements WebRTC for client use. Its full implementation is seemingly difficult to get right. Of course, you're right that this implementation is very small. It's very different than a typical client implementation, I don't share the same concerns. It's also only the WHIP portion of WebRTC, and anyone processing user input through ffmpeg is hopefully compiling a version enabling only the features they use, or at least "--disable-muxer=whip" and others at configure time. Or, you know, you could specify everything explicitly at runtime so ffmpeg won't load features based on variable user input.
  - gruez 1y ago
    >I assume autoexec is referring to the plethora of WebRTC vulnerabilities which have affected browsers, messengers, and any other software which implements WebRTC for client use. Its full implementation is seemingly difficult to get right. Like what? I did a quick search and most seem to be stuff like ip leaks and fingerprinting, which isn't relevant in ffmpeg.
    - lpln3452 1y ago
      This is exactly the question I have. While WebRTC causes fingerprinting risks in browsers, isn’t that unrelated to running ffmpeg?
    - globie 1y ago
      Here's a (very) small sample gathered from a search for "webrtc" on cve.org and picking high-severity CVEs affecting browsers: * CVE-2015-1260 * CVE-2022-4924 * CVE-2023-7010 * CVE-2023-7024 * CVE-2024-3170 * CVE-2024-4764 * CVE-2024-5493 * CVE-2024-10488 Of course, I agree that it's not relevant to ffmpeg. But seeing "WebRTC" triggers the same part of the brain that looks out for unescaped SQL statements. Good opportunity to point out the difference in this implementation.
      - therealpygon 1y ago
        So you searched “WebRTC”, and then took the extraordinary step of… not actually reading any of them while simultaneous using them as supposed points? Quick question since you seem to know a lot about these CVEs and have spent a fair amount of time understanding them: how many of those were browser implementation issue? This is like searching CVE for “node” and then claiming Node is terrible because some node packages have vulnerabilities. Low effort and intended to fit evidence to an opinion instead of evaluating evidence. “Linux” has 17,000 results; using your critical lens, all Linux is insecure.
        globie 1y ago
        When writing this inflammatory post, you seem to have forgot the bigger picture of the thread you are flaming. We're discussing whether it's right to take a second look from a security standpoint when a software implements WebRTC. In this case, it's nuanced, and the implementation in FFmpeg is very different than the more complete implementations you find in browsers. And when browsers have implemented WebRTC, many vulnerabilities have followed. So the double-take is justified here, even if only in principle. No one is saying WebRTC is insecure, or FFmpeg, or node, or Linux.......... I did a cursory read of each CVE. Wherever you got the idea I did not, you must have forgot to include it in your post. Just now, I picked one from random. It reports "Multiple WebRTC threads could have claimed a newly connected audio input leading to use-after-free." Does that exactly qualify as an "implementation bug"? I don't know, and I don't care, because how you taxonomize a CVE has nothing to do with whether it's a vulnerability that was introduced when implementing WebRTC. And it is.
    - fc417fc802 1y ago
      > stuff like ip leaks and fingerprinting, which isn't relevant in ffmpeg. If ffmpeg implements WHEP in the future then I'd certainly be concerned about both of those things when viewing a stream. Probably less so for serving a stream up, particularly via a gateway (the current implementation IIUC).
- autoexec 1y ago
  most recently: https://cyberpress.org/critical-libvpx-vulnerability-in-firefox https://cyberpress.org/critical-libvpx-vulnerability-in-fire..., but you can have your pick from any year https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webrtc https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webrtc You're right that biggest reason people usually recommend disabling it is to prevent your IP from leaking when using a VPN https://www.techradar.com/vpn/webrtc-leaks https://www.techradar.com/vpn/webrtc-leaks but not having to worry about RCE or DoS is a nice bonus I'm not sure how much will this impact ffmpeg users. Considering that WebRTC has a bad track record in terms of security though, I do worry a little that its inclusion in one more place on our systems could increase attack surface.
  - Sean-Der 1y ago
    Those are issues in multiple implementations though! Lots of them are just issues in Chromium around Javascript (webrtc code wasn't even started yet) That would be like saying saying 'webrtc is more secure then http' by posting this https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=http https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=http IP Leaking has been fixed since 2019[0]. ICE/P2P is still a huge attack surface though. I have seen lots of other tricks being tried. [0] https://www.youtube.com/watch?v=SqcW8kJAMJg https://www.youtube.com/watch?v=SqcW8kJAMJg
- codedokode 1y ago
  Leaking local IP addresses?
mschuster91 1y ago
> Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems. ffmpeg has had so many issues in the past [1], it's best practice anyway to keep it well contained when dealing with user input. Create a docker image with nothing but ffmpeg and its dependencies installed and do a "docker run" for every transcode job you got. Or maybe add ClamAV, OpenOffice and ImageMagick in the image as well if you also need to deal with creating thumbnails of images and document. And personally, I'd go a step further and keep the servers that deal with user-generated files in more than accepting and serving them in their own, heavily locked down VLAN (or Security Group if you're on AWS). That's not a dumbass criticism of any of these projects mentioned by the way. Security is hard, especially when dealing with binary formats that have inherited a lot of sometimes questionably reverse engineered garbage. It's wise to recognize this before getting fucked over like 4chan was. [1] https://ffmpeg.org/security.html https://ffmpeg.org/security.html
- xxpor 1y ago
  if you're worried about arbitrary code exec from an ffmpeg vuln, docker is not a sufficient security boundary.
  - baggy_trough 1y ago
    What is?
    - ethersteeds 1y ago
      Full virtualization. Docker implies a shared kernel attack surface, that's what you want to avoid.
      - afiori 1y ago
        Kernel level exploits are more dangerous but also way less common, for a lot of places docker is sorta okay as a security boundary
        1y ago
dylan604 1y ago
is this something that one could compile with a --without-whip type of argument if you don't want/need? that would an ideal thing.
- marxisttemp 1y ago
  Yes, pretty much every bit of ffmpeg can be enabled or disabled when compiling.
morepedantic 1y ago
ffmpeg is high performance code dealing with esoteric codecs and binary formats in C, so don't sweat it.

Sean-Der 1y ago

What security flaws? This implementation is very small. I feel 100% confident we are giving users the best thing possible.

globie 1y ago
I assume autoexec is referring to the plethora of WebRTC vulnerabilities which have affected browsers, messengers, and any other software which implements WebRTC for client use. Its full implementation is seemingly difficult to get right. Of course, you're right that this implementation is very small. It's very different than a typical client implementation, I don't share the same concerns. It's also only the WHIP portion of WebRTC, and anyone processing user input through ffmpeg is hopefully compiling a version enabling only the features they use, or at least "--disable-muxer=whip" and others at configure time. Or, you know, you could specify everything explicitly at runtime so ffmpeg won't load features based on variable user input.
- gruez 1y ago
  >I assume autoexec is referring to the plethora of WebRTC vulnerabilities which have affected browsers, messengers, and any other software which implements WebRTC for client use. Its full implementation is seemingly difficult to get right. Like what? I did a quick search and most seem to be stuff like ip leaks and fingerprinting, which isn't relevant in ffmpeg.
  - lpln3452 1y ago
    This is exactly the question I have. While WebRTC causes fingerprinting risks in browsers, isn’t that unrelated to running ffmpeg?
  - globie 1y ago
    Here's a (very) small sample gathered from a search for "webrtc" on cve.org and picking high-severity CVEs affecting browsers: * CVE-2015-1260 * CVE-2022-4924 * CVE-2023-7010 * CVE-2023-7024 * CVE-2024-3170 * CVE-2024-4764 * CVE-2024-5493 * CVE-2024-10488 Of course, I agree that it's not relevant to ffmpeg. But seeing "WebRTC" triggers the same part of the brain that looks out for unescaped SQL statements. Good opportunity to point out the difference in this implementation.
    - therealpygon 1y ago
      So you searched “WebRTC”, and then took the extraordinary step of… not actually reading any of them while simultaneous using them as supposed points? Quick question since you seem to know a lot about these CVEs and have spent a fair amount of time understanding them: how many of those were browser implementation issue? This is like searching CVE for “node” and then claiming Node is terrible because some node packages have vulnerabilities. Low effort and intended to fit evidence to an opinion instead of evaluating evidence. “Linux” has 17,000 results; using your critical lens, all Linux is insecure.
      - globie 1y ago
        When writing this inflammatory post, you seem to have forgot the bigger picture of the thread you are flaming. We're discussing whether it's right to take a second look from a security standpoint when a software implements WebRTC. In this case, it's nuanced, and the implementation in FFmpeg is very different than the more complete implementations you find in browsers. And when browsers have implemented WebRTC, many vulnerabilities have followed. So the double-take is justified here, even if only in principle. No one is saying WebRTC is insecure, or FFmpeg, or node, or Linux.......... I did a cursory read of each CVE. Wherever you got the idea I did not, you must have forgot to include it in your post. Just now, I picked one from random. It reports "Multiple WebRTC threads could have claimed a newly connected audio input leading to use-after-free." Does that exactly qualify as an "implementation bug"? I don't know, and I don't care, because how you taxonomize a CVE has nothing to do with whether it's a vulnerability that was introduced when implementing WebRTC. And it is.
  - fc417fc802 1y ago
    > stuff like ip leaks and fingerprinting, which isn't relevant in ffmpeg. If ffmpeg implements WHEP in the future then I'd certainly be concerned about both of those things when viewing a stream. Probably less so for serving a stream up, particularly via a gateway (the current implementation IIUC).
autoexec 1y ago
most recently: https://cyberpress.org/critical-libvpx-vulnerability-in-firefox https://cyberpress.org/critical-libvpx-vulnerability-in-fire..., but you can have your pick from any year https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webrtc https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webrtc You're right that biggest reason people usually recommend disabling it is to prevent your IP from leaking when using a VPN https://www.techradar.com/vpn/webrtc-leaks https://www.techradar.com/vpn/webrtc-leaks but not having to worry about RCE or DoS is a nice bonus I'm not sure how much will this impact ffmpeg users. Considering that WebRTC has a bad track record in terms of security though, I do worry a little that its inclusion in one more place on our systems could increase attack surface.
- Sean-Der 1y ago
  Those are issues in multiple implementations though! Lots of them are just issues in Chromium around Javascript (webrtc code wasn't even started yet) That would be like saying saying 'webrtc is more secure then http' by posting this https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=http https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=http IP Leaking has been fixed since 2019[0]. ICE/P2P is still a huge attack surface though. I have seen lots of other tricks being tried. [0] https://www.youtube.com/watch?v=SqcW8kJAMJg https://www.youtube.com/watch?v=SqcW8kJAMJg
codedokode 1y ago
Leaking local IP addresses?

mschuster91 1y ago

> Hopefully this doesn't make it more dangerous to keep ffmpeg on our systems. ffmpeg has had so many issues in the past [1], it's best practice anyway to keep it well contained when dealing with user input. Create a docker image with nothing but ffmpeg and its dependencies installed and do a "docker run" for every transcode job you got. Or maybe add ClamAV, OpenOffice and ImageMagick in the image as well if you also need to deal with creating thumbnails of images and document. And personally, I'd go a step further and keep the servers that deal with user-generated files in more than accepting and serving them in their own, heavily locked down VLAN (or Security Group if you're on AWS). That's not a dumbass criticism of any of these projects mentioned by the way. Security is hard, especially when dealing with binary formats that have inherited a lot of sometimes questionably reverse engineered garbage. It's wise to recognize this before getting fucked over like 4chan was. [1] https://ffmpeg.org/security.html https://ffmpeg.org/security.html

xxpor 1y ago
if you're worried about arbitrary code exec from an ffmpeg vuln, docker is not a sufficient security boundary.
- baggy_trough 1y ago
  What is?
  - ethersteeds 1y ago
    Full virtualization. Docker implies a shared kernel attack surface, that's what you want to avoid.
    - afiori 1y ago
      Kernel level exploits are more dangerous but also way less common, for a lot of places docker is sorta okay as a security boundary
      - 1y ago

dylan604 1y ago

is this something that one could compile with a --without-whip type of argument if you don't want/need? that would an ideal thing.

marxisttemp 1y ago
Yes, pretty much every bit of ffmpeg can be enabled or disabled when compiling.

morepedantic 1y ago

ffmpeg is high performance code dealing with esoteric codecs and binary formats in C, so don't sweat it.