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.
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.
>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.
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.
>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?
>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.
Did inserting the Huawei E353 dongle attach a virtual CD-ROM drive that you manually installed drivers from? I know for a fact similar devices (eg, ZTE MF910) offer drivers this way. In my experience with such devices, the USB drivers that are built into Linux works fine (just like Android USB tethering), so there isn't any need to run the Huawei or ZTE driver installation.
It's worth mentioning these USB On-The-Go devices (including Android phones and 4G modems) have relatively powerful processors and run a wide variety of network services, including a web server that will never receive security patches (for the end-user web configuration interface), have your high-precision location information. The devices have a high bandwidth internet side-channel (the 4G connection itself) while also having the ability to act as any USB client device (including keyboards to send keystrokes to your computer to eg, open a command prompt and run software).
They are incredibly powerful platforms for targeted cyberattacks and I imagine state actors are using them very often.
Considering China is a communist dictatorship, the company is the state, in a way.
Now my biggest guess is that xhost + is being used to allow a process running as root to launch a window into the existing xserver no matter what (probably a graphical client).
It's a very bad practice though. How comes that devices can autorun software nowadays?
There is a few mechanisms through which hardware can get the OS to execute code, so it is possible for the BIOS to cause software to be installed. E.g. the easiest one is probably the "Windows Platform Binary Table" in ACPI.
(I do not see that line in the article) but that is the point; who made this? Who says this is legit? Perhaps bought off Aliexpress? Or rebadged by the provider?
The "USB Stick" you refer to is the "E353 HSPA+ 3G USB stick" being the device itself; also called the "Surf stick". Google it.
some quick googling suggests that "autorun" appears to be some sort of usb wifi dongle driver or something, not "state sponsored hacking". Talk about jumping to conclusions
Would this be done to permit a driver to create windows on the desktop from some place where it couldn't use :0 like normal? E.g. it can't use a Unix socket and needs to use TCP?
I'm very inexpert with X11, but have run remote apps on a local X11 server. But are there any scenarios locally (e.g. chroot) that could be blocking the Unix socket approach for a driver?
I worked with Huawei back when the first dongles of this kind started coming to market (some time after 2004, in the 3G days). Their QA was virtually non-existent, and it took us something like twelve tries to get a hybrid (Mac/PC) image preloaded onto it.
The Windows drivers were unsigned, the “dashboard” application for managing the dongle was horrible (and the Mac version, which I was especially responsible for, was so bad I eventually asked to provide a modem script instead). But I could not attribute any of it to malice, really (as the saying goes...).
And yes, those things usually have a plethora of USB functionality inside them, from a USB UART (Ethernet in some variants) to storage, which usually had drivers and carrier-specific apps to configure the dongles.
Now, this post does pose some questions, but not necessarily about Huawei - last I checked, Linux had no autorun functionality, so I’m wondering if the author didn’t actually run some portion of their installer without thinking of the consequences?
I have used several these sticks (Huawei E353, E3131 and others). You plug them in, they are automatically handled by usb-modeswitch and show a few CDC serial ports (one for PPP, one for AT commands and one that I'm not sure what is for). You run ppp on the port (I guess this is also managed automatically by NetworkManager in more user-friendly distros) and it connects you to the internet. Nothing is being installed in the process. (maybe there indeed is some Linux driver from Huawei, but I see no reason for installing it)
25 comments
[ 4.6 ms ] story [ 74.0 ms ] thread>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.
Laptops travel to coffee shops and share their network.
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.
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.
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?
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.
It's worth mentioning these USB On-The-Go devices (including Android phones and 4G modems) have relatively powerful processors and run a wide variety of network services, including a web server that will never receive security patches (for the end-user web configuration interface), have your high-precision location information. The devices have a high bandwidth internet side-channel (the 4G connection itself) while also having the ability to act as any USB client device (including keyboards to send keystrokes to your computer to eg, open a command prompt and run software).
They are incredibly powerful platforms for targeted cyberattacks and I imagine state actors are using them very often.
I would expect it from Huawei, but not exclusive to them.
Now my biggest guess is that xhost + is being used to allow a process running as root to launch a window into the existing xserver no matter what (probably a graphical client).
It's a very bad practice though. How comes that devices can autorun software nowadays?
Edit: Case in point - this comment was flagged less than five minutes after it was posted.
The "USB Stick" you refer to is the "E353 HSPA+ 3G USB stick" being the device itself; also called the "Surf stick". Google it.
[0]: https://consumer.huawei.com/en/press/news/2011/hw-256113/
I'm very inexpert with X11, but have run remote apps on a local X11 server. But are there any scenarios locally (e.g. chroot) that could be blocking the Unix socket approach for a driver?
The Windows drivers were unsigned, the “dashboard” application for managing the dongle was horrible (and the Mac version, which I was especially responsible for, was so bad I eventually asked to provide a modem script instead). But I could not attribute any of it to malice, really (as the saying goes...).
And yes, those things usually have a plethora of USB functionality inside them, from a USB UART (Ethernet in some variants) to storage, which usually had drivers and carrier-specific apps to configure the dongles.
(My notes on the E220 are still around - https://taoofmac.com/space/com/Huawei/E220 has a bunch of low-level stuff I had actually forgotten about)
Now, this post does pose some questions, but not necessarily about Huawei - last I checked, Linux had no autorun functionality, so I’m wondering if the author didn’t actually run some portion of their installer without thinking of the consequences?