3 ms·

Less than ideal behavior, but this bit is nonsense: >This command makes your Linux desktop remotely accessible to anyone on the network It's definitely not a

by FDSGSG 6y ago

Less than ideal behavior, but this bit is nonsense: >This command makes your Linux desktop remotely accessible to anyone on the network It's definitely not a common configuration to have X11 listening for network connections. In a multiuser environment this could actually be a problem, but I doubt there are many multiuser environments running this driver. On a single user machine like a laptop, this really doesn't matter at all. Yes, a process running as another user could mess with your X11 session. But if you get compromised somehow that process will almost certainly be running as your current user or root.

dleslie 6y ago
> In a multiuser environment this could actually be a problem, but I doubt there are many multiuser environments running this driver. Laptops travel to coffee shops and share their network.
- phone8675309 6y ago
  I think the point that the GP is trying to make is that most Linux distributions over the last 15 or so years do not allow X to listen on the network by default anymore. There used to be a specific network port for each X display that would listen on the network, and it was the main way of displaying remote clients on your local display server until the advent of SSH X11 forwarding. There are two primary ways that the 'xhost +' command could be an issue on a multiuser machine these days (assuming that X11 not listening on the network): other users on the machine can now access your X11 session with no access control (as 'xhost +' disables access control) or that a remote code execution exploit against a daemon running on the network can be used to access your X11 session with no access control.
phone8675309 6y ago
>Yes, a process running as another user could mess with your X11 session. But if you get compromised somehow that process will almost certainly be running as your current user or root. This means that any daemon with a remote code execution exploit (even if running as its own, compartmentalized user) can now be chained with this to get complete access to your X11 session.
- FDSGSG 6y ago
  And how many such daemons do you have running on your laptop? My debian install only has tor and avahi. Any adversary with 0days for those would certainly have linux kernel exploits too.
  - phone8675309 6y ago
    >And how many such daemons do you have running on your laptop? Typically none, but the security of someone else's system is not defined by the security of my system. For some users, they might have CUPS running because they have a printer configured, SSH so that people can connect to help them (or so they can push files to the machine over the network), perhaps they're doing some web development and have Apache running. There are any number of daemons that could be running on a laptop with legitimate access to the rest of the network. > Any adversary with 0days for those would certainly have linux kernel exploits too. I wouldn't say that's a given, first off, and second off, they may not have a Linux kernel exploit, and even if they do, why should they burn a Linux 0day when they can simply just listen using this open hole?
    - FDSGSG 6y ago
      >they might have CUPS running because they have a printer configured Runs as root. >SSH so that people can connect to help them Runs as root. >perhaps they're doing some web development and have Apache running I think you're fundamentally screwed if your adversary is willing to use apache 0days on you. >There are any number of daemons that could be running on a laptop with legitimate access to the rest of the network In practice this is a very rare scenario, the severity of this fuckup by Huawei should be viewed in that light. It's not ideal, but this is hardly a big deal. >why should they burn a Linux 0day Those are a dime in a dozen, and using an exploit very rarely means burning it. And even if the adversary didn't have a linux 0day to use on you, you'd almost certainly still be screwed sooner or later as they'd now have persistent local access to your system. Odds are that you'd never notice a cronjob running as debian-tor, pinging the attackers c&c once a day. It really is game over once someone gets arbitrary code execution on your system, unless you maintain an extraordinary security posture which would preclude installing sketchy huawei drivers anyway.

by FDSGSG 6y ago

dleslie 6y ago

> In a multiuser environment this could actually be a problem, but I doubt there are many multiuser environments running this driver. Laptops travel to coffee shops and share their network.

phone8675309 6y ago
I think the point that the GP is trying to make is that most Linux distributions over the last 15 or so years do not allow X to listen on the network by default anymore. There used to be a specific network port for each X display that would listen on the network, and it was the main way of displaying remote clients on your local display server until the advent of SSH X11 forwarding. There are two primary ways that the 'xhost +' command could be an issue on a multiuser machine these days (assuming that X11 not listening on the network): other users on the machine can now access your X11 session with no access control (as 'xhost +' disables access control) or that a remote code execution exploit against a daemon running on the network can be used to access your X11 session with no access control.

phone8675309 6y ago

>Yes, a process running as another user could mess with your X11 session. But if you get compromised somehow that process will almost certainly be running as your current user or root. This means that any daemon with a remote code execution exploit (even if running as its own, compartmentalized user) can now be chained with this to get complete access to your X11 session.

FDSGSG 6y ago
And how many such daemons do you have running on your laptop? My debian install only has tor and avahi. Any adversary with 0days for those would certainly have linux kernel exploits too.
- phone8675309 6y ago
  >And how many such daemons do you have running on your laptop? Typically none, but the security of someone else's system is not defined by the security of my system. For some users, they might have CUPS running because they have a printer configured, SSH so that people can connect to help them (or so they can push files to the machine over the network), perhaps they're doing some web development and have Apache running. There are any number of daemons that could be running on a laptop with legitimate access to the rest of the network. > Any adversary with 0days for those would certainly have linux kernel exploits too. I wouldn't say that's a given, first off, and second off, they may not have a Linux kernel exploit, and even if they do, why should they burn a Linux 0day when they can simply just listen using this open hole?
  - FDSGSG 6y ago
    >they might have CUPS running because they have a printer configured Runs as root. >SSH so that people can connect to help them Runs as root. >perhaps they're doing some web development and have Apache running I think you're fundamentally screwed if your adversary is willing to use apache 0days on you. >There are any number of daemons that could be running on a laptop with legitimate access to the rest of the network In practice this is a very rare scenario, the severity of this fuckup by Huawei should be viewed in that light. It's not ideal, but this is hardly a big deal. >why should they burn a Linux 0day Those are a dime in a dozen, and using an exploit very rarely means burning it. And even if the adversary didn't have a linux 0day to use on you, you'd almost certainly still be screwed sooner or later as they'd now have persistent local access to your system. Odds are that you'd never notice a cronjob running as debian-tor, pinging the attackers c&c once a day. It really is game over once someone gets arbitrary code execution on your system, unless you maintain an extraordinary security posture which would preclude installing sketchy huawei drivers anyway.