8 ms·

That's pretty bad. It's been known for decades on other Unix systems that you shouldn't pass passwords by command line parameter, or even support doing so. I gu

by catern 9y ago

That's pretty bad. It's been known for decades on other Unix systems that you shouldn't pass passwords by command line parameter, or even support doing so. I guess no-one told Apple.

RantyDave 9y ago
Exactly. More to the point, even if it doesn't log it any more, I bet it's still on the command line itself.
- cjbprime 9y ago
  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.
  - pentagonpapers 9y ago
    Bad idea cat /proc/<pid>/environ
    - cjbprime 9y ago
      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.
      - pentagonpapers 9y ago
        Sure, it still leaves room for malware etc accessing data if it's running as the main user. I think the better solution is to read it out of a wallet into stdin
      - BenjiWiebe 9y ago
        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.
        cjbprime 9y ago
        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
        tetha 9y ago
        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.
      - Fnoord 9y ago
        > On Linux, since you're using /proc. Exactly; macOS doesn't use /proc.
deleted 9y ago
[deleted]
SSLy 9y ago
Not to disagree, but could you provide some references to the statement?
- alister 9y ago
  >> 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/ 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-programming.html http://faqs.cs.uu.nl/na-dir/unix-faq/programmer/secure-progr...
- tinus_hn 9y ago
  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.
  - your-nanny 9y ago
    So what is the proper way?
chrisfinazzo 9y ago
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).

by catern 9y ago

That's pretty bad. It's been known for decades on other Unix systems that you shouldn't pass passwords by command line parameter, or even support doing so. I guess no-one told Apple.

RantyDave 9y ago

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

cjbprime 9y ago
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.
- pentagonpapers 9y ago
  Bad idea cat /proc/<pid>/environ
  - cjbprime 9y ago
    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.
    - pentagonpapers 9y ago
      Sure, it still leaves room for malware etc accessing data if it's running as the main user. I think the better solution is to read it out of a wallet into stdin
    - BenjiWiebe 9y ago
      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.
      - cjbprime 9y ago
        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
        tetha 9y ago
        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.
    - Fnoord 9y ago
      > On Linux, since you're using /proc. Exactly; macOS doesn't use /proc.

deleted 9y ago

[deleted]

SSLy 9y ago

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

alister 9y ago
>> 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/ 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-programming.html http://faqs.cs.uu.nl/na-dir/unix-faq/programmer/secure-progr...
tinus_hn 9y ago
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.
- your-nanny 9y ago
  So what is the proper way?

chrisfinazzo 9y ago

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).