Exactly. More to the point, even if it doesn't log it any more, I bet it's still on the command line itself.

The usual trick here is to pass it as an environment variable instead of cmdline, that can be done without much effort so they're probably doing that.

Bad idea

cat /proc/<pid>/environ

Wait, what's your threat model? Surely you're not imagining that you can pass data from one process to another without root being able to see it? (On Linux, since you're using /proc.)

Other users' processes can't see /proc/$pid/environ, unlike using cmdline.

Don't recall right now for sure, but doesn't ps have an option to display the processes environment? I've done it by accident a few times and it does not take root.

It has an option (e) to attempt to display environment variables, but ps is just a program that reads from /proc, and the kernel enforces isolation of environment variables by breaking reads to /proc/pid/environ for processes you don't own (or more precisely, can't ptrace), so `ps e` can't show anything for those processes.

  λ whoami
  cjb
  λ cat /proc/1/cmdline
  /sbin/init%
  λ cat /proc/1/environ
  cat: /proc/1/environ: Permission denied

And if you can see /proc/*/environ, you can probably attach to the process via gdb and read the secret from the process memory. At that point, it's not relevant how the secret was passed to the process.

Unless the secret is some kind of one-time token, or time based token, but then it's also not relevant how the secret was passed to the process. It's invalidated soon.

> On Linux, since you're using /proc.

Exactly; macOS doesn't use /proc.

But really, how big of an attack surface is there? By that I mean, how many people have external encrypted APFS drives?

By my estimation, I would guess the number is smaller than people think for a few reasons.

1. How many people who aren't technically saavy have external drives at all? If they do, it's probably a Time Machine volume. Which leads me to my second point...

2. Directory hardlinks - the tech which makes TM work - don't exist on APFS, so a fair number of these drives are probably still using HFS+, and last I checked, external SSDs of any sufficient capacity are still pretty costly, which brings me to the last point...

3. Given that APFS is really SSD-only (with a small asterisk for Fusion Drives), converting a TM volume on a spinning disk is a recipe for pain.

I'm not excusing the bug, only reiterating that its effect is probably less than you might imagine among people who aren't nerds (or HN readers for that matter).

Not to disagree, but could you provide some references to the statement?

>> It's been known for decades on other Unix systems that you shouldn't pass passwords by command line parameter

> could you provide some references to the statement?

If you search the Usenet archives, you can find many discussions about this. It's one of those topics that came up frequently in the comp.unix newsgroup as early as 1991 that I see in some messages.

Usenet discussion from 1994:

"ps e gets you a processes environment. It is totally unsafe to store anything that should be secret. if there needs to be secret data, the best way to get it is with scanf(), once the program is running."[1]

And here is the Secure UNIX Programming FAQ from 1999:

"A security hole related to FreeBSD's 'ps' utility. The utility would allow users to view another process' environment variables. Consequently applications like pppd that accepted passwords via environment variables became vulnerable to unauthorized release of privileged information attacks. In fact, thehole was not related to 'ps' if you think about it critically. The application that places privileged information in the environment variable is at fault."[2]

[1]https://groups.google.com/forum/m/#!search/ then search for "ps shows command line parameters" (for the exact message, search for "ps e gets you a processes environment")

[2]http://faqs.cs.uu.nl/na-dir/unix-faq/programmer/secure-progr...

If you run the ps command you can see all processes with all the command line arguments. They’re not secret, which is why you shouldn’t put passwords there.

Now typically these processes only run for a short time so it’s difficult to catch passwords manually but it’s predictable so a script can.

So what is the proper way?

Either store them in environment variables or pass them through file descriptors, such as standard input.

Note that you do need to take care to clean up the environment if you create new, unprivileged subprocesses or these secrets may leak.

Thanks.