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
defensive coding styles. (Very few routines that work on memory buffers
take the buffer size as a parameter, for example.)
And the collection of #ifdefs to work on dozens of no-longer-mainstream
OSes certainly complicate reading and understanding the code. (Which is
why cppcheck reports many configurations that can't possibly compile.)
Any program that uses socat MUST be very careful. It's got a much larger
attack surface than e.g. nc. If nc can solve a problem as well as socat,
then nc should be preferred. But socat can handle millions of cases that
netcat cannot handle.
Some tips for application authors:
- Do not allow dynamic input to be used as command line arguments
- Do not allow dynamic input to be used as environment variables
Trying to sanitize dynamic inputs for these uses would be challenging.
Security team ACK for promoting socat to main.
This looked like a bug:
- xiosetsockaddrenv() is the strcpy() here intentional:
case PF_INET6:
strcpy(namebuff, lr);
Thanks
** Changed in: socat (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1756870
Title:
[MIR] socat
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/socat/+bug/1756870/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
