[MIR] socat

[Julian Andres Klode]

[Availability]
Available in universe, built on all architectures.

[Rationale]
socat is a tool like netcat, but with support for ssl. It has recently become a requirement for GKE and thus should be in main.

[Security]
The tracker lists two open CVEs, but it is wrong - they have been fixed quite some time ago.

[Quality assurance]
Upstream has a test suite, but it is not run. socat has an important bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793384 - it uses to few bits for DH parameters by default. But that was marked as fixed, so OK.

[Dependencies]
Build-Depends: debhelper (>= 10), libssl-dev, libwrap0-dev.

[Standards compliance]

[Maintenance]
The package is relatively small, but since it interfaces with (potentially SSL) sockets, it might need some security updates. Otherwise it can be kept in sync with Debian.

[Background information]
There was a previous MIR attempt in https://bugs.launchpad.net/ubuntu/+source/socat/+bug/829234

[Mathieu Trudel-Lapierre (cyphermox)]

At a glance, the tests should be runnable; please enable them if possible.

Given the use of OpenSSL, and previous issues with DH length, let's have this reviewed by the Security team.

[Julian Andres Klode (juliank)]

Uploaded socat with tests enabled (most of them, some fail due to OpenSSL 1.1 and cipher negotiation restrictions in there)

[Seth Arnold (seth-arnold)]

BTW, the 'justification' in this bug (socat) is accidentally copied from the pv bug. Could you update this to say why socat is desired at the moment?

Thanks

[Julian Andres Klode (juliank)]

The argument is the same, both are needed for GKE stuff. Apparently for some proxying stuff or something.

[Seth Arnold (seth-arnold)]

I reviewed socat version 1.7.3.2-2build1 as checked into Bionic. This
shouldn't be considered a full security audit but rather a quick gauge of
reliability.

socat is all-purpose fd / socket / pipe manipulator tool. It's either a
very deft way to quickly and easily solve a problem or a very high-powered
footgun. Proper programmatic use of socat looks *extremely* difficult due
to magic environment variables, easy ability to execute other programs,
and general flexibility.

There are six CVEs against socat currently in our database; some of these
might legitimately have been deemed "not a security issue" due to threat
models but were handled all the same. One particularly embarrassing CVE
included a composite DH parameter. The faulty parameter was available for
roughly a year. This incident served as a reminder to the wider community
that open source software is vulnerable to malicious contributions the
same as proprietary products; I'm glad the socat team were honest.

- Build-Depends: debhelper, libssl-dev, libwrap0-dev
- Offers cryptography
- Does not daemonize (daemon.sh shell script just backgrounds the task
  from the shell)
- Listens to nearly every networking protocol, interface, etc
- No pre/post inst/rm scripts
- No init scripts
- No systemd unit files
- No dbus services
- No setuid files
- socat, procan, and filan programs in PATH
- No sudo fragments
- No udev rules
- There's tests but not run as part of the package build, unknown value
- No cron jobs
- Some deprecation warnings in the build logs

- Subprocesses are spawned, driven by command line parameters if they go
  through system() or execve() (SYSTEM: and EXEC: methods)
- Some memory management was careful, some was 80s-style use of
  static-sized buffers and "knowing" that inputs won't overflow these
  buffers. The few cases of unsafe buffer use that I chased down all had
  static strings as inputs, and thus looked safe. But several CVEs address
  this very issue.
- Files are written too, driven by command line parameters
- Logging is extensive, including strace-style wrappers around every
  system call and library function used. Can also log through syslog.
- Extensive environment variable manipulation and use. The manpage
  describes the full range of environment variables and how they are used.
  The few that I inspected looked safe. Applications that use socat
  without being aware of environment use will probably have security
  vulnerabilities.
- Extensive use of ioctls, fchown, chroot, setgroups, setgid, setuid,
  chmod, chown; some driven by command line options (so calling programs
  MUST NOT allow unauthenticated unsanitized input here)
- Extensive use of cryptography -- can be configured to ignore or perform
  certificate validation, fake results, etc.
- Extensive networking
- Code that drops privileges looked careful
- No temporary files
- No WebKit
- No JavaScript
- No PolicyKit
- cppcheck reports real bugs but most would kill the build, though

socat is difficult choice. Its utility is obvious, and I've used it dozens
of times to solve little problems over the years. But so much of the code
relies upon being perfect C programmers for safety rather than using
de...

[Matthias Klose (doko)]

Override component to main
socat 1.7.3.2-2ubuntu2 in bionic: universe/net -> main
socat 1.7.3.2-2ubuntu2 in bionic amd64: universe/net/extra/100% -> main
socat 1.7.3.2-2ubuntu2 in bionic arm64: universe/net/extra/100% -> main
socat 1.7.3.2-2ubuntu2 in bionic armhf: universe/net/extra/100% -> main
socat 1.7.3.2-2ubuntu2 in bionic i386: universe/net/extra/100% -> main
socat 1.7.3.2-2ubuntu2 in bionic ppc64el: universe/net/extra/100% -> main
socat 1.7.3.2-2ubuntu2 in bionic s390x: universe/net/extra/100% -> main
7 publications overridden.