User Enumeration via Timing Side-Channel in Public Key Authentication

[XK3NF4]

Summary

Dropbear SSH 2025.89 is vulnerable to user enumeration through timing analysis during public key authentication. An unauthenticated remote attacker can determine valid usernames by measuring response time differences caused by filesystem I/O operations.

Technical Details

Affected Component: svr-authpubkey.c
CWE: CWE-208 (Observable Timing Discrepancy)

Vulnerability Analysis

In svr-authpubkey.c, the function svr_auth_pubkey() exhibits different code paths for valid and invalid users:

Invalid User Path (lines ~160-167):

if (!valid_user) {
    /* Return failure once we have read the contents of the packet */
    send_msg_userauth_failure(0, 0);  // incrfail = 0, NO timing delay
    goto out;
}

Valid User Path:

// Continues to checkpubkey() which performs:
// - fopen() on /home/username/.ssh/authorized_keys
// - File permission checks (stat/fstat)
// - File content reading
if (auth_failure) {
    auth_failure = checkpubkey(keyalgo, keyalgolen, keyblob, keybloblen);
}

Root Cause

The critical issue is that send_msg_userauth_failure() is called with incrfail = 0 for invalid users in public key authentication. This means the adaptive timing delay (250-350ms) implemented in svr-auth.c to mitigate timing attacks is NOT applied.

Comparison with Password Authentication (Protected):

// Password auth applies timing delay
send_msg_userauth_failure(0, 1);  // incrfail = 1

Public Key Auth (Vulnerable):

// Publickey auth does NOT apply timing delay
send_msg_userauth_failure(0, 0);  // incrfail = 0

Cheers,
xk3nf4

[mkj]

In testing here I see a few millisecond timing leak on each pubkey query for valid users, testing on a normal laptop with SSD. I'm not sure why the larger delay is seen above - how many attempts were averaged? What kind of system is it?

I'll have a think about the best way to mitigate this. A fixed adaptive delay for every publickey query would be undesirable in the normal case, and difficult to size correctly.

The best option might be to read authorized_keys once on first publickey query and have a random adaptive delay there.

[XK3NF4]

You are completely right that the timing differences vary significantly depending on the underlying hardware and environment.

To give you more context, I conducted my tests across three different environments:

• A remote VPS
• A Mac with an M1 chip (local)
• A virtualized Kali Linux machine

Just as you observed, on both the VPS and the M1 Mac, the timing difference between a valid and an invalid user is indeed much smaller only a few milliseconds. However, the leak is still consistently measurable.

The larger delays I initially reported were observed in my virtualized Kali Linux setup.