Consider protecting against HDMI-based attacks

[andrewdavidwong]

Discussion thread:

https://groups.google.com/d/topic/qubes-users/ZENcuxGUqRQ/discussion

[v6ak]

Maybe this could be divided into multiple types of attack with various security impact, various controversy (i.e., risk of breaking legitimate functionality) and maybe various milestone. I'll try to sum it up:

• HDMI ethernet – high security impact, no controversy (dom0 is not expected to have ethernet connection)
• Audio return channel – rather small security impact (well, potentially compressed data), some controversy
• CEC – minimal security impact, small controversy
• DDC – small security impact, high controversy
• HotPlug – virtually no security impact, high controversy

You see, ensuring that HDMI Ethernet is off should have highest relative priority in my opinion. I hope reasons are obvious: Dom0 is expected to be outdated, so some known network-related vulnerability (remember glibc DNS vulnerability…) can be there for months.

[v6ak]

Maybe this could be divided into multiple types of attack with various security impact, various controversy (i.e., risk of breaking legitimate functionality) and maybe various milestone. I'll try to sum it up:

• HDMI ethernet – high security impact, no controversy (dom0 is not expected to have ethernet connection)
• Audio return channel – rather small security impact (well, potentially compressed data), some controversy
• CEC – minimal security impact, small controversy
• DDC – small security impact, high controversy
• HotPlug – virtually no security impact, high controversy

You see, ensuring that HDMI Ethernet is off should have highest relative priority in my opinion. I hope reasons are obvious: Dom0 is expected to be outdated, so some known network-related vulnerability (remember glibc DNS vulnerability…) can be there for months.

[DemiMarie]

@v6ak The easy fix for that is to do an rm -rf of the network driver tree.

[DemiMarie]

@v6ak The easy fix for that is to do an rm -rf of the network driver tree.

[v6ak]

Thank you for the suggestion. I might be wrong, but disabling HDMI network might be much harder than a simple rm -rf: * Not sure if we can remove support for networking completely. Loopback might be needed by some apps. (Hmm, maybe KDE uses some servers on loopback?) It might also be a trouble in future, e.g., when adding Gnome support or when upgrading to a newer KDE version. I would suggest against this way. * Removing specific drivers might be the way, except that, well, some network drivers might be hidden in GPU drivers. I am not sure, maybe all GPU drivers with such capability have a separate optional kernel module and they follow a clear naming scheme for that. But I am not that optimistic. If you have some further suggestion on that (maybe you know the structure if drivers better…), I believe it will be welcome.

[v6ak]

Thank you for the suggestion. I might be wrong, but disabling HDMI network might be much harder than a simple rm -rf: * Not sure if we can remove support for networking completely. Loopback might be needed by some apps. (Hmm, maybe KDE uses some servers on loopback?) It might also be a trouble in future, e.g., when adding Gnome support or when upgrading to a newer KDE version. I would suggest against this way. * Removing specific drivers might be the way, except that, well, some network drivers might be hidden in GPU drivers. I am not sure, maybe all GPU drivers with such capability have a separate optional kernel module and they follow a clear naming scheme for that. But I am not that optimistic. If you have some further suggestion on that (maybe you know the structure if drivers better…), I believe it will be welcome.

[Aekez]

I'm speculating whether there are any filters of sorts that forces an HDMI cable to be one-directional, instead of bi-directional (default HDMI state). It's a bit murky water as there is a lot of speculation and assumptions on HDMI out there, and very little reliable clarification, so searching for reliable answers becomes a bit tiresome on the wild-wild-west on some of the HDMI information.

Generally, if one can attain a filter, switch, amplifier, or similar, that either directly or indirectly enforces a one-directional communication of HDMI, it might be more assuring to protect from HDMI hacks with a physical analogical device, rather than software protections (especially if the HDMI TV has Internet / Bluetooth / WiFi capability, which makes it really scary to connect it to Qubes dom0). Just removing drivers etc. still makes me a bit uneasy, especially considering this issue is still open for long-term milestone far into the future, and not closed.

So far I've had no luck finding a physical device, filter, switch, or otherwise, that enforces a one-direction of HDMI with certainty. This could potentially be a good fix against HDMI hacks, if found though.

A potential quick and easy solution?
For example, if a HDMI switch doesn't have the bi-directional HDMI feature that HDMI normally has, would such a lack of feature, truly enforce a protected one-directional HDMI connection? and could a lack of a feature, be enough to justify protective measures from bi-directional communications? Further, such a switch should probably act more like an analogue system rather than digital, due to firmware exploits? Does anyone maybe know of a filter/switch/or-similar that has no firmware, and acts like a one-directional HDMI connection? If so, at least we have a short-term solution until the isolation protective measures catches up.

[Aekez]

I'm speculating whether there are any filters of sorts that forces an HDMI cable to be one-directional, instead of bi-directional (default HDMI state). It's a bit murky water as there is a lot of speculation and assumptions on HDMI out there, and very little reliable clarification, so searching for reliable answers becomes a bit tiresome on the wild-wild-west on some of the HDMI information.

Generally, if one can attain a filter, switch, amplifier, or similar, that either directly or indirectly enforces a one-directional communication of HDMI, it might be more assuring to protect from HDMI hacks with a physical analogical device, rather than software protections (especially if the HDMI TV has Internet / Bluetooth / WiFi capability, which makes it really scary to connect it to Qubes dom0). Just removing drivers etc. still makes me a bit uneasy, especially considering this issue is still open for long-term milestone far into the future, and not closed.

So far I've had no luck finding a physical device, filter, switch, or otherwise, that enforces a one-direction of HDMI with certainty. This could potentially be a good fix against HDMI hacks, if found though.

A potential quick and easy solution?
For example, if a HDMI switch doesn't have the bi-directional HDMI feature that HDMI normally has, would such a lack of feature, truly enforce a protected one-directional HDMI connection? and could a lack of a feature, be enough to justify protective measures from bi-directional communications? Further, such a switch should probably act more like an analogue system rather than digital, due to firmware exploits? Does anyone maybe know of a filter/switch/or-similar that has no firmware, and acts like a one-directional HDMI connection? If so, at least we have a short-term solution until the isolation protective measures catches up.

[v6ak]

I have a poor Internet connection, so my response will be brief and by heart: * As I probably have noted, double passive conversion (HDMI –> DVI and DVI –> HDMI) removes most inputs, except some monitor identification (EDID or so), which is rather minor concern. This solution is easy and cheap. You have to care about connector gender (male/female), of course. You can verify it by finding HDMI wiring and HDMI to DVI converters mapping. You also can measure the two converters by some ohmmeter to verify some pins are dicsonnected. * Active converters can have their own vulnerabilities. OTOH, attacks on them would be probably matter of some well targeted attacks unless there is some wide-spread type. * Pure software solution could offer some protection. However, it can protect just from attacks to the OS, not from attacks to the GPU firmware. Not sure what to do from Qubes side. Maybe: * Documentation? * Pure software countermeasures might be still reasonable basic protection. -- Sent from my fruity BlackBerry device with K-9 Mail. Please excuse my brevity.

[v6ak]

I have a poor Internet connection, so my response will be brief and by heart: * As I probably have noted, double passive conversion (HDMI –> DVI and DVI –> HDMI) removes most inputs, except some monitor identification (EDID or so), which is rather minor concern. This solution is easy and cheap. You have to care about connector gender (male/female), of course. You can verify it by finding HDMI wiring and HDMI to DVI converters mapping. You also can measure the two converters by some ohmmeter to verify some pins are dicsonnected. * Active converters can have their own vulnerabilities. OTOH, attacks on them would be probably matter of some well targeted attacks unless there is some wide-spread type. * Pure software solution could offer some protection. However, it can protect just from attacks to the OS, not from attacks to the GPU firmware. Not sure what to do from Qubes side. Maybe: * Documentation? * Pure software countermeasures might be still reasonable basic protection. -- Sent from my fruity BlackBerry device with K-9 Mail. Please excuse my brevity.

[DemiMarie]

We should definitely have software-based countermeasures. Not everyone will get hardware components.

…

On Mon, Jul 2, 2018, 6:41 AM Vít Šesták ***@***.***> wrote: I have a poor Internet connection, so my response will be brief and by heart: * As I probably have noted, double passive conversion (HDMI –> DVI and DVI –> HDMI) removes most inputs, except some monitor identification (EDID or so), which is rather minor concern. This solution is easy and cheap. You have to care about connector gender (male/female), of course. You can verify it by finding HDMI wiring and HDMI to DVI converters mapping. You also can measure the two converters by some ohmmeter to verify some pins are dicsonnected. * Active converters can have their own vulnerabilities. OTOH, attacks on them would be probably matter of some well targeted attacks unless there is some wide-spread type. * Pure software solution could offer some protection. However, it can protect just from attacks to the OS, not from attacks to the GPU firmware. Not sure what to do from Qubes side. Maybe: * Documentation? * Pure software countermeasures might be still reasonable basic protection. -- Sent from my fruity BlackBerry device with K-9 Mail. Please excuse my brevity. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2743 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB0-9fawH2CRhRSBEcyuC2vo5SbGkks5uCfjPgaJpZM4M4S4s> .

[DemiMarie]

We should definitely have software-based countermeasures. Not everyone will get hardware components.

…

On Mon, Jul 2, 2018, 6:41 AM Vít Šesták ***@***.***> wrote: I have a poor Internet connection, so my response will be brief and by heart: * As I probably have noted, double passive conversion (HDMI –> DVI and DVI –> HDMI) removes most inputs, except some monitor identification (EDID or so), which is rather minor concern. This solution is easy and cheap. You have to care about connector gender (male/female), of course. You can verify it by finding HDMI wiring and HDMI to DVI converters mapping. You also can measure the two converters by some ohmmeter to verify some pins are dicsonnected. * Active converters can have their own vulnerabilities. OTOH, attacks on them would be probably matter of some well targeted attacks unless there is some wide-spread type. * Pure software solution could offer some protection. However, it can protect just from attacks to the OS, not from attacks to the GPU firmware. Not sure what to do from Qubes side. Maybe: * Documentation? * Pure software countermeasures might be still reasonable basic protection. -- Sent from my fruity BlackBerry device with K-9 Mail. Please excuse my brevity. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2743 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB0-9fawH2CRhRSBEcyuC2vo5SbGkks5uCfjPgaJpZM4M4S4s> .

[Aekez]

@v6ak

(HDMI –> DVI and DVI –> HDMI)

This looks very, very interesting, I'm definitely gonna look into this soon, thanks for sharing! Maybe even combine it with the other suggestions, so protection hopefully becomes stacked / overlapping-redundant as far as possible.

@DemiMarie
I can only agree, but we're still some time off into the future before we can get good pure software solutions though? i.e. as v6ak mentioned, dom0 graphics is still exposed atm, but that "might" change some in Qubes 4.1. with isolated graphics away from dom0 though, but that's still some time off. I wonder if Qubes 4.1. would be enough though? i.e. while dom0 is protected, could attacks still be made to graphics to attack from one VM to the next VM, even with the new protective measures of Qubes 4.1.?

However I guess you mean that relying on hardware solutions puts less urgency on making a software solution, thereby potentially delaying a solution that could work for every Qubes user, rather than just those who get the extra hardware? If that is what you mean, then I can only agree with you, though I hope we can manage to focus on both hardware and software solutions. At least I'd like to see some more details on the software solution and covering any potential loose ends, before I can relax on a more software-based solution. It definitely makes me uneasy to have such potential attack surfaces.

About a doc on this
If interested in making a joint collaboration on a doc on various different (hardware / software) HDMI protective measures, we could start progressive work on one over at Qubes Collaboration Community, where the intention is collaborative work for Qubes related docs/code/scripts.

[Aekez]

@v6ak

(HDMI –> DVI and DVI –> HDMI)

This looks very, very interesting, I'm definitely gonna look into this soon, thanks for sharing! Maybe even combine it with the other suggestions, so protection hopefully becomes stacked / overlapping-redundant as far as possible.

@DemiMarie
I can only agree, but we're still some time off into the future before we can get good pure software solutions though? i.e. as v6ak mentioned, dom0 graphics is still exposed atm, but that "might" change some in Qubes 4.1. with isolated graphics away from dom0 though, but that's still some time off. I wonder if Qubes 4.1. would be enough though? i.e. while dom0 is protected, could attacks still be made to graphics to attack from one VM to the next VM, even with the new protective measures of Qubes 4.1.?

However I guess you mean that relying on hardware solutions puts less urgency on making a software solution, thereby potentially delaying a solution that could work for every Qubes user, rather than just those who get the extra hardware? If that is what you mean, then I can only agree with you, though I hope we can manage to focus on both hardware and software solutions. At least I'd like to see some more details on the software solution and covering any potential loose ends, before I can relax on a more software-based solution. It definitely makes me uneasy to have such potential attack surfaces.

About a doc on this
If interested in making a joint collaboration on a doc on various different (hardware / software) HDMI protective measures, we could start progressive work on one over at Qubes Collaboration Community, where the intention is collaborative work for Qubes related docs/code/scripts.

[DemiMarie]

Yes, that is what I was referring to. Also, I hope for Qubes to someday get hardware-accelerated rendering (one use case is running untrusted Steam games), which requires strong GPU virtualization.

…

On Mon, Jul 2, 2018, 9:40 AM Yuraeitha ***@***.***> wrote: @v6ak <https://github.com/v6ak> (HDMI –> DVI and DVI –> HDMI) This looks very, very interesting, I'm definitely gonna look into this soon, thanks for sharing! Maybe even combine it with the other suggestions, so protection hopefully becomes stacked / overlapping-redundant as far as possible. @DemiMarie <https://github.com/DemiMarie> I can only agree, but we're still some time off into the future before we can get good pure software solutions though? i.e. as v6ak mentioned, dom0 graphics is still exposed atm, but that "might" change some in Qubes 4.1. with isolated graphics away from dom0 though, but that's still some time off. I wonder if Qubes 4.1. would be enough though? i.e. while dom0 is protected, could attacks still be made to graphics to attack from one VM to the next VM, even with the new protective measures of Qubes 4.1.? However I guess you mean that relying on hardware solutions puts less urgency on making a software solution, thereby potentially delaying a solution that could work for every Qubes user, rather than just those who get the extra hardware? If that is what you mean, then I can only agree with you, though I hope we can manage to focus on both hardware and software solutions. At least I'd like to see some more details on the software solution and covering any potential loose ends, before I can relax on a more software-based solution. It definitely makes me uneasy to have such potential attack surfaces. *About a doc on this* If interested in making a joint collaboration on a doc on various different (hardware / software) HDMI protective measures, we could start progressive work on one over at Qubes Collaboration Community <https://github.com/Qubes-Community/Qubes-Community.github.io>, where the intention is collaborative work for Qubes related docs/code/scripts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2743 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWBx67xBifMEltQVx-hdPzc2VlKLwAks5uCiLUgaJpZM4M4S4s> .

[DemiMarie]

Yes, that is what I was referring to. Also, I hope for Qubes to someday get hardware-accelerated rendering (one use case is running untrusted Steam games), which requires strong GPU virtualization.

…

On Mon, Jul 2, 2018, 9:40 AM Yuraeitha ***@***.***> wrote: @v6ak <https://github.com/v6ak> (HDMI –> DVI and DVI –> HDMI) This looks very, very interesting, I'm definitely gonna look into this soon, thanks for sharing! Maybe even combine it with the other suggestions, so protection hopefully becomes stacked / overlapping-redundant as far as possible. @DemiMarie <https://github.com/DemiMarie> I can only agree, but we're still some time off into the future before we can get good pure software solutions though? i.e. as v6ak mentioned, dom0 graphics is still exposed atm, but that "might" change some in Qubes 4.1. with isolated graphics away from dom0 though, but that's still some time off. I wonder if Qubes 4.1. would be enough though? i.e. while dom0 is protected, could attacks still be made to graphics to attack from one VM to the next VM, even with the new protective measures of Qubes 4.1.? However I guess you mean that relying on hardware solutions puts less urgency on making a software solution, thereby potentially delaying a solution that could work for every Qubes user, rather than just those who get the extra hardware? If that is what you mean, then I can only agree with you, though I hope we can manage to focus on both hardware and software solutions. At least I'd like to see some more details on the software solution and covering any potential loose ends, before I can relax on a more software-based solution. It definitely makes me uneasy to have such potential attack surfaces. *About a doc on this* If interested in making a joint collaboration on a doc on various different (hardware / software) HDMI protective measures, we could start progressive work on one over at Qubes Collaboration Community <https://github.com/Qubes-Community/Qubes-Community.github.io>, where the intention is collaborative work for Qubes related docs/code/scripts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2743 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWBx67xBifMEltQVx-hdPzc2VlKLwAks5uCiLUgaJpZM4M4S4s> .