Cisco Open-Sources H.264 Codec, Pushes WebRTC

[curaga]

NSA backdoor, really?
In a video codec?

Get back on earth...
The codec cannot have access (because you can sandbox it and/or measure what access it is asking for, and compare it to the source) to:
- network
- files on your computer
- user and kernel land programs of your computer

Firefox sandboxes nothing. TFA is about Firefox. Therefore the codec does have access to everything you listed, it is a binary running with your user rights.

[smitty3268]

Firefox sandboxes nothing. TFA is about Firefox. Therefore the codec does have access to everything you listed, it is a binary running with your user rights.

But maybe they'll sandbox this, since they're already writing special code just for it? They've already got plugin code running in a separate process, and they will know exactly which rights this code should and shouldn't have, so it'd be really easy.

The fact is that we don't know what kind of access rights this codec will have, because it hasn't been added yet.

[curaga]

The seccomp sandboxes require cooperation. It's entirely possible FF cannot sandbox the codec without a framework such as SELinux or Smack.

You're right that this is speculation. Still, it's such a big hole if it ends up working that way.

[erendorn]

The seccomp sandboxes require cooperation. It's entirely possible FF cannot sandbox the codec without a framework such as SELinux or Smack.

You're right that this is speculation. Still, it's such a big hole if it ends up working that way.

Sure, but the you don't need it to be sandboxed everywhere. You need it to be sandboxed/monitored at least once, and see it request at least once a resource that shouldn't be requested based on source, for the backdoor to be detected.
This just makes it an unpractical backdoor, and as such, an implausible one.

[uid313]

Sure, but the you don't need it to be sandboxed everywhere. You need it to be sandboxed/monitored at least once, and see it request at least once a resource that shouldn't be requested based on source, for the backdoor to be detected.
This just makes it an unpractical backdoor, and as such, an implausible one.

You cannot monitor it for suspicious behavior when any backdoor may be activated by an unknown sequence that you do not know of.
Any such backdoor will probably be masqueraded as a bug though.

[erendorn]

You cannot monitor it for suspicious behavior when any backdoor may be activated by an unknown sequence that you do not know of.
Any such backdoor will probably be masqueraded as a bug though.

I'm sure this could be used against individual untargeted users provided you can check by some other vector that these users do not have any security measure (SELinux, for example, prevents AND log breaches attempts).

It still quite unpractical to only target users that have absolutely zero binary programs on their PC but this codec, that actually use this codec (you won't if you have hardware or OS support), that do not have sandboxing/monitoring capabilities, that can be determined separately that they don't have these capabilities, that use VOIP through the web and using this codec, and that communicate things worth listening to directly (not just for metadata) through it.
=> implausible.

Regarding it being masqueraded as a bug, I completely agree, yet they will still have to deactivate it after being caught.