FYI: Security review of ipp-usb by SUSE

[jsmeix]

This is only to have you informed.

At SUSE we did a security review of ipp-usb
https://bugzilla.opensuse.org/show_bug.cgi?id=1221671

Here a copy of the findings, see
https://bugzilla.opensuse.org/show_bug.cgi?id=1221671#c6

Matthias Gerstner 2024-04-04 13:18:56 UTC 

I finished looking into the package.
It's about 10.000 lines of Golang.
The code mostly looks well organized and readable.
Interestingly the systemd service is kind of autostarted
via the udev rules that are shipped.
As soon a compatible printer device is plugged in,
the service starts via udev.

Authorization and Networking
============================

The major pain point is the networking / authorization model.
By default the service only listens on localhost.
For localhost there also exists a simple authentication
scheme based on user ids and groups.
This is configured via /etc/ipp-usb/ipp-usb.conf.
The owner of a localhost TCP connection is determined
via special Linux TCP diagnostic socket APIs.
A bit overkill IMHO (maybe it could have been done
via a UNIX domain socket in some way), but okay.

If the daemon is allowed to listen on all interfaces then,
the printer becomes available over http://
in the local network.
If authentication is configured then requests can be sent
from remote but all such requests will be rejected,
because they cannot be authorized.
This means a networked printer is only accessible,
if authentication is disabled.
This seems a bit strange at first,
but in fact is consistent on a logical level
and does not leave a false impression on admins
(I configured authentication, thus it is safe).
It would be even better not to listed on the network
at all though, if authentication is enabled.

Not only that remote connections cannot be authorized,
but there is also no support for SSL encryption
and thus also not for any kind of integrity.
So print jobs sent over the network
will leak to observers of network traffic.
The data can also be manipulated.
Thus using ipp-usb on the network is absolutely something
that must limited to completely trusted, small networks.

The package is still okay for Factory in my opinion,
because the network access is disabled by default,
and even if it is enabled, then the firewall will
still prevent access by default.
Thus if somebody enables this on both ends,
then they hopefully really know what they're doing.
It's also unlikely that this happens in a mobile setup,
e.g. if somebody uses this at home with their laptop
and takes the laptop to work, then the printer
will likely not be taken along to work,
i.e. ipp-usb will not be running in the work scenario.

Local UNIX Domain Socket
========================

The ipp-usb daemon also serves a local UNIX domain socket
in /var/ipp-usb/ctrl.
This socket is world accessible.
An HTTP listener is attached to this socket.
But it only supports GET requests for the /status URL,
everything else is rejected.
The /status GET only returns some text describing
the current runtime status.
So it is uncritical for local security.

Session Handling limited to 1000 IDs
====================================

For some reason the session IDs on HTTP and USB level
are limited to 1000 distinct IDs:

https://github.com/OpenPrinting/ipp-usb/blob/0.9.25/usbtransport.go#L412

https://github.com/OpenPrinting/ipp-usb/blob/0.9.25/http.go#L84

So the session numbers are limited and predictable.
When using unencrypted HTTP this could make spoofing easier.
But since we don't have any networking security anyway,
I don't think it's a problem, just a curiosity.

Hardening Suggestion
====================

The ipp-usb service currently runs with full root privileges.
This seems a bit much for what is does.
On the networking side it only listens on ports > 1024
by default, so this doesn't require special permissions.
The only interesting bit is the access to the USB devices
via libusb.

A hardening could be to install udev rules
that grant access to ipp-usb for matching USB devices,
either via a group assignment, or an ACL entry.
Then ipp-usb could run with lowered privileges,
greatly reducing attack surface.
Maybe this is something you can approach upstream with.

[alexpevzner]

Hi @jsmeix,

thank you for review!

I would convert it from "issue" into "discussion", so it may stay open forever and there will be no need to somehow "fix" it and close.

[alexpevzner]

Thank you for review. My few comments:

I finished looking into the package.
It's about 10.000 lines of Golang.

Please notice that https://github.com/OpenPrinting/goipp is logically also part of the ipp-usb. I've moved it into the separate package for convenience of people who may want to use goipp as a general-purpose IPP library (surprisingly, there were no such a library when ipp-usb was created)

It would be even better not to listed on the network
at all though, if authentication is enabled.

When I listen on all network interfaces and then manually reject unwanted incoming connections, it is implementable in few lines of Go code.

Listening to the network selectively requires individual listener per every network interface (or, to be more correct, per every IP address of any network interface). It requires dynamic monitoring of IP configuration change, dynamic adding/removing listeners, brrr. A bit overcomplicated, I'd like to avoid this complexity where possible.

Not only that remote connections cannot be authorized,
but there is also no support for SSL encryption

Implementing SSL is considerable (at least in theory) but the good design is required. The major concern is management of certificates. I guess the manual management ("put certificate into directory XXX") would be a bit too difficult to understand, so not too much people will use it.

For some reason the session IDs on HTTP and USB level
are limited to 1000 distinct IDs:

https://github.com/OpenPrinting/ipp-usb/blob/0.9.25/usbtransport.go#L412

These sessions are only exist with the purpose to match related requests and responses in logs. So this is OK to have limited IDs space. The purpose of this limitation is to keep these numbers relatively small, comfortable for human eyes.

A hardening could be to install udev rules
that grant access to ipp-usb for matching USB devices,
either via a group assignment, or an ACL entry.

My major concern here is how to implement this stuff so it will work on any Linux distro (at least, any major distro). Not sure they all have the similar settings for groups etc.

[mikhailnov]

My major concern here is how to implement this stuff so it will work on any Linux distro (at least, any major distro). Not sure they all have the similar settings for groups etc.

udev rules from systemd upstream assume the "lp" group, for example. all wide-spread distros that I know use it. Some exotic distros may patch a yet another component if needed, I think.