Research
Security News
Quasar RAT Disguised as an npm Package for Detecting Vulnerabilities in Ethereum Smart Contracts
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
github.com/openprinting/ipp-usb
IPP-over-USB allows using the IPP protocol, normally designed for network printers, to be used with USB printers as well.
The idea behind this standard is simple: It allows to send HTTP requests to the device via a USB connection, so enabling IPP, eSCL (AirScan) and web console on devices without Ethernet or WiFi connections.
Unfortunately, the naive implementation, which simply relays a TCP connection to USB, does not work. It happens because closing the TCP connection on the client side has a useful side effect of discarding all data sent to this connection from the server side, but it does not happen with USB connections. In the case of USB, all data not received by the client will remain in the USB buffers, and the next time the client connects to the device, it will receive unexpected data, left from the previous abnormally completed request.
Actually, it is an obvious flaw in the IPP-over-USB standard, but we have to live with it.
So the implementation, once the HTTP request is sent, must read the entire HTTP response, which means that the implementation must understand the HTTP protocol, and effectively implement a HTTP reverse proxy, backed by the IPP-over-USB connection to the device.
And this is what the ipp-usb program actually does.
Though looks simple, ipp-usb does many non obvious things under the hood
Being written on Go, ipp-usb has a large executable size. However, its memory consumption is not very high. When single device is connected, ipp-usb RSS is similar or even slightly less in comparison to ippusbxd. And because ipp-usb handles all devices in a single process, it uses noticeably less memory that ippusbxd, when serving 2 or more devices.
This program has very few external dependencies, namely:
libusb
for USB accesslibavahi-common
and libavahi-client
for DNS-SDBinary packages available for the following Linux distros:
Linux Mint users may use Ubuntu packages:
Follow this link for downloads: https://download.opensuse.org/repositories/home:/pzz/
We are glad to announce that ipp-usb
was recently included into the
FreeBSD ports: https://www.freshports.org/print/ipp-usb/
Hope, NetBSD/OpenBSD support will be added as well, so technology becomes not Linux-only, but UNIX-wide.
ipp-usb is also available as a Snap in the Snap Store: https://snapcraft.io/ipp-usb
Before you install the Snap, uninstall any already existing installation of ipp-usb.
Simply install it via any GUI client for the Snap Store (Like "Ubuntu Software") or via command line:
sudo snap install --edge ipp-usb
Now you can connect and disconnect IPP-over-USB devices and ipp-usb gets started by the Snap whenever needed. Also devices which are already connected during boot, start, or update of the Snap are considered.
You can also use
ipp-usb status
to check the status of the running ipp-usb daemon (supported device must be connected for the ipp-usb daemon to be running, accesses only the ipp-usb daemon of the Snap) and
ipp-usb check
to scan the USB for the presence of potentially supported USB devices (7/1/4 interface protocol). This command requires access to the raw USB and therefore on many systems root privileges are required.
The Snap is automatically updated when further development on ipp-usb happens.
The configuration file is here:
/var/snap/ipp-usb/common/etc/ipp-usb.conf
You can edit it and afterwards restart the Snap to use the changed configuration.
Incompatibilities of particular devices are handled by workarounds defined in the quirk files. You find them here:
/var/snap/ipp-usb/common/quirks
You can add your own quirk files (but if they solve your problem, please report an issue here, with your quirk file attached, so that others with the same problem will get helped, too).
For quick tests you can also edit the existing files, but they will get replaced (and so your changes lost) on the next update of the Snap, as we are changing them on any report of further device incompatibilities.
The log file is here
/var/snap/ipp-usb/common/var/log
and device state files (to assure that each device appears on the same port and with the same DNS-SD service name) are here:
/var/snap/ipp-usb/common/var/dev
You can also build the Snap locally. This is useful when
To do so, run from the main directory of this source repository
snapcraft snap
and then install the resulting Snap with
sudo snap install --dangerous ipp-usb*.snap
An installed Snap from the Snap Store will get overwritten/replaced by your Snap.
Some technical notes about this Snap:
Snapping the Go project with one Go library taken from upstream (and not from Ubuntu Core) was rather straight-forward. Only observation was that the Go plugin seems not to do "make install". So I had to use an "override-build" to manually install the auxiliary files (ipp-usb.conf, quirk files). I also have adapted the auxiliary file and state directories in paths.go in the "override-build" scriptlet.
The real challenge of this Snap was to trigger ipp-usb on the appearing (and also the presence) of IPP-over-USB devices.
In the classic installation of ipp-usb (via "make install" or RPM/DEB package installation) a UDEV rules file and a systemd service file (in systemd-udev/) are installed, so that the system automatically triggers the launch of ipp-usb when an appropriate device is connected or already present. A Snap is not able to do so. It cannot install any files into the system. It can only bring its own, static file system and create files only in its own state directory. These locations are not scanned for UDEV rules.
So the Snap must discover the devices without its own UDEV rules, but it still can use UDEV. The trick is to do a generic monitoring of UDEV events and filtering out the USB devices with IPP-over-USB interface (7/1/4). If such a device appears, we trigger and ipp-usb launch. We also check on startup of the Snap whether there is such a device already and if so, we also trigger an ipp-usb launch.
ipp-usb is run, as in the classic installation, with "udev" argument. This way it stops by itself when there is no device any more (and we do not need to observe the disappearal events of the devices) and it is assured that only one single instance of ipp-usb is running.
To do this with low coding effort I use the UDEV command line tool udevadm in a shell script (snap/local/run-ipp-usb). Once it runs in "monitor" mode to observe the UDEV events. Then we parse the output lines to only consider the ones for a device appearing and run "udevadm info -q property" on each device path, to get the properties and filter the 7/1/4 interface. In the beginning we use "udevadm trigger" to find the already passed appearal event of a device which is already present. So the shell script is an auxiliary daemon to start ipp-usb when needed.
You will need to install the following packages (exact name depends of your Linux distro):
Building is really simple:
git clone https://github.com/OpenPrinting/ipp-usb.git
cd ipp-usb
make
Then you may make install
or just try to run ./ipp-usb
directly from
the build directory
IPP-over-USB normally exposes printer to localhost only, hence it requires DNS-SD announces to work for localhost.
This requires Avahi 0.8.0 or newer. Older Avahi versions do not support announcing to localhost.
Some Linux distros (for example recent Ubuntu and Fedora versions) have their Avahi patched to support localhost, others (for example Debian) not.
To determine if your Avahi supports localhost, run the following command in one terminal session:
avahi-publish -s test _test._tcp 1234
And simultaneously the following command in another terminal session on the same machine:
avahi-browse _test._tcp -r
If you see localhost in the avahi-browse output, like this:
= lo IPv4 test _test._tcp local
hostname = [localhost]
address = [127.0.0.1]
port = [1234]
txt = []
your Avahi is OK. Otherwise, update or patching is required.
So users of distros that ship a too old Avahi and without the patch have three possibilities:
ipp-usb
to run on all network interfaces, not only on loopbackIf you decide to apply the patch, get it as avahi/avahi-localhost.patch
in this package or download it here.
The third method is simple to do, just replace interface = loopback
with interface = all
in the ipp-usb.conf
file, but this has the
disadvantage of exposing your local USB-connected printer to the
entire local network, which can be an unwanted side effect, especially
in a big corporative network.
FAQs
Unknown package
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.