Insecure use of /dev/shm

[Jakub Wilk]

/dev/shm is world-writable, so you need to be careful when creating files or directories there.
This silently succeeds when /dev/shm/pa is owned by a (potentially malicious) local user:

    tmpfile="/dev/shm/pa/$name.txt"
    tmpdir="$(dirname "$tmpfile")"
    mkdir -p "$tmpdir"

[j3s]

ty for raising this @jwilk! ❤️

for my own curiosity: even if a malicious local user owns the parent dir, I'm not seeing how that causes a security issue. all pa edit files are still created as the effective user w/ a 077. I tested setting the setgid bit on a maliciously-owned dir, and couldn't figure out any way for a malicious user to read any data by simply owning the dir.

could you help me understand how dir ownership == data breach?

i did discover that by owning specific files, malicious users could gain access to password data. i patched this in 6b9c395 - the patch also resolves any malicious dir ownership concerns, i believe.

[Jakub Wilk]

could you help me understand how dir ownership == data breach?

On Linux, the attacker can do:

$ mkdir -m 777 /dev/shm/pa
$ setfacl -d -m "u:$LOGNAME:r" /dev/shm/pa

Then all files created in /dev/shm/pa will be readable to the attacker.

[j3s]

Gotcha - thank you for that, I totally forgot about extended ACLs. I just pushed 0ea7ee1, which I've tested against the use-case you outlined & several others - I think it's safe. I'd appreciate if you could look it over & let me know if you think it's sound.

[Jakub Wilk]

It's not good.

First of all, denial of sevice is still possible. If the attacker created /dev/shm/pa, then nobody else (except root) could use pa edit.

Moreover, rm -rf /dev/shm/pa is advertised as a security measure, but it actually make things worse. It may delete your own /dev/shm/pa when it's still in use by another pa edit instance, possibly enabling worse-than-DoS attacks.

You should use mktemp -d /dev/shm/pa.XXXXXX (or something similar) for creating temporary directories.

[j3s]

@jwilk ty for the feedback, again. i went through it this morning & i wound up simplifying pw_edit quite a bit - here's the latest version:

pa/pa

Lines 41 to 77 in 31a28df

 pw_edit() { 
     name=$1 
  
     [ -f "$name.age" ] || 
         die "Couldn't access $name" 
  
     # Use /dev/shm because it's an in-memory 
     # space that we can use to store private data 
     # & securely wipe it 
     [ -d /dev/shm ] || 
         die "Couldn't access /dev/shm" 
  
     # Reimplement mktemp here, because 
     # mktemp isn't defined in POSIX 
     tmpdir="/dev/shm/pa.$(rand_chars 8 '[:alnum:]')" 
  
     tmpfile="$tmpdir/$name.age" 
  
     mkdir "$tmpdir" || 
         die "Couldn't create shared memory dir" 
  
     trap "rm -rf $tmpdir" EXIT 
  
     # Handle nested items (/foo/bar.age) 
     mkdir -p "$(dirname $tmpfile)" 
  
     age --decrypt -i "$identities_file" -o "$tmpfile" "$name.age" || 
         die "Couldn't decrypt $name.age" 
  
     "${EDITOR:-vi}" "$tmpfile" 
  
     [ -f "$tmpfile" ] || 
         die "New password not saved" 
  
     age --encrypt -R "$recipients_file" -o "$name.age" "$tmpfile" || 
         die "Couldn't encrypt $name.age" 
 } 

I think that this protects against all of the classes of security issue you outline above, as well as the potential DoS attacks you pointed out.

Thoughts?

[Jakub Wilk]

6cd0cdb looks good to me.

[j3s]

thx for the report & reviews ❤️ i'll close this now.