OpenBSD had too many arguments

UNIX Philosophy & Untrusted Inputs

In a system designed along traditional UNIX principles, subcomponents are run as child processes and receive their inputs from three sources:

  • A list of NUL-terminated strings passed to main() by the kernel ("arguments"). The number of arguments is known in advance and their space is pre-allocated, which is sometimes nice, but the NUL terminator prevents them from containing binary data. Also, there's a (platform-specific[1]) limit on the total size of the argument buffer.
  • A list of NUL-terminated key-value string pairs accessible with the global symbol extern char **environ or the libc function getenv() ("environment variables"). These have the interesting property of automatically propagating to child processes, so they're often used for cross-cutting configuration such as network proxy addresess.
  • A pseudo-file ("standard input"). This can handle arbitrary binary data (and arbitrary amounts of data) but there's no portable way for the subproces to figure out how big the input is. It's also less portable to barely-POSIX platforms like Windows.

None of these have much in the way of semantics – they're just blobs of bytes – and so even careful programmers struggle to propagate and parse inputs correctly in all circumstances. Thus CVE-2019-19522, in which OpenBSD (a security-obsessed living fossil of an OS) disclosed a remotely exploitable authentication bypass caused by bad input handling.

The problem is obvious if you read the manual with security goggles on:

For any given style, the program /usr/libexec/auth/login_style is used to
perform the authentication.  The synopsis of this program is:

/usr/libexec/auth/login_style [-v name=value] [-s service] username class

Yep! It's that easy! If the attacker sends a username of -swhatever [2], it gets mixed right into the program's arguments and interpreted as a trusted configuration option rather than untrusted input.

To be fair this isn't OpenBSD's fault, exactly – it's hard to maintain strict compatibility with a 40歳 operating system written at Berkeley and also have reasonable security properties. And they're hardly alone: the Common Gateway Interface (CGI) specifies that GET parameters can be passed as arguments!

This periodically surprises people who write language runtimes; they want to consume internal configuration from arguments, and other people want to write CGI scripts for some reason, and then you end up with tickets like GHC #3910:

The fact that every ghc-compiled program accepts +RTS options could be a security problem in several contexts. For example, if you compile a “Hello, world!” program and make it setuid root, any user can now overwrite any file on the system using root privileges: hello +RTS -t/etc/passwd.

In other areas of the UNIX world people use environment variables for this stuff and then you get Shellshock. Or you can try your luck with undelimited stdin and get a buffer overflow like CVE-2004-0548. There's just no way to win here.

Google brass set 2023 as deadline to bring back Google Reader

Looks like Mountain View is at it again:

[Google Cloud], which sells computing services to big companies, is under pressure from top management to pass Microsoft or Amazon—currently first and second, respectively, in cloud market share—or risk losing funding. While the company has invested heavily in the business since last year, Google wants its cloud group to outrank those of one or both of its two main rivals by 2023, said people with knowledge of the matter.

The group, which included Google CEO Sundar Pichai, Alphabet chief financial officer Ruth Porat and then-CEO of Alphabet Larry Page, discussed whether Google could “win” in the business, who would be best to lead the effort and the difficulties of competing on things other than technology, such as sales and marketing.

On one hand, it is good to see Google management acknowledge there's more to selling hosted compute infrastructure than just slapping together some tech demos and calling it a product. On the other, this raises the questions of (1) what exactly Google's strategy was for the last ten years, (2) how they intend to recover from ceding the entire market to Amazon and Microsoft (two companies not typically viewed as gentle competitors).

Probably the answer is something like: Google will hire all the PhDs, who will design good computers, and then Google will tell potential customers how good their computers are. This does not seem materially different from what they do today, except maybe the last part. Also, the best time to leverage their strength in high-performance datacenter hardware engineering[3] would have been before Amazon started renting access to in-house 64-core ARM silicon in volume.

A more radical change would be: Google asks their customers what they wanted to buy, then builds and sells it. I sometimes joke that Google divides the world into "Google" and "Joe's Bait Shack", and this may be a little unfair but it doesn't seem wrong. The years-long delay between AppEngine and GCE is the behavior of a management that believes Google understands their customers' needs better than the customers do. Meanwhile Amazon has mastered the art of selling things without judgement. They'll sell you a bag of choco-mint coffee, they'll drive a tractor trailer to your building to copy data into hosted NFS, there is no limit to how dumb an idea can be if it contributes net margin.

  1. Traditional UNIX systems have large argument buffers, anywhere from 32 KiB (i386 Linux) to 1 MiB (Solaris). Windows, which in contemporary incarnations is technically POSIX-compliant, has a much lower limit – 2048 bytes.

  2. Most UNIX-style option parsers treat -s foo and -sfoo the same.

  3. Google also has an advantage in software engineering, visible in features like live VM migration, or the pricing plans of Coldline vs Glacier. But even here they're not invulnerable – Coldline's successor, the "ice cold" storage class, is still MIA months after being announced. And I would expect it's easier for Amazon to add live migration to Nitro than it is for Google to change its approach to customer support at the same time it's fighting other internal culture wars.