Invalid signature key type allows to trigger an assertion via remote

[nbars]

Hey, I found a bug in the dbclient that can be triggered in a release build from remote. Since signkey.c is likely also used by the server, this assert could also be triggered on the server.

The following assert is triggered:

dropbear/src/signkey.c

Line 186 in 910af60

assert((int)sigtype < (int)DROPBEAR_SIGNKEY_NUM_NAMED);

If the assert is disabled via NDEBUG this could probably lead to undefined behavior due to a cast of the unsanitized value

dropbear/src/signkey.c

Line 187 in 910af60

return (enum signkey_type)sigtype;

I used the following command for compilation:

git clone https://github.com/mkj/dropbear.git src
cd src
git checkout 9925b005e5b71080535afc94955ef2fe8c9d4c77

export CFLAGS="-g -O3 -fsanitize=address"
export CXXFLAGS="-g -O3 -fsanitize=address"
export LDFLAGS="-fsanitize=address"

./configure
make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" -j

And this is the backtrace of the triggered bug:

=================================================================
==1078583==ERROR: AddressSanitizer: ABRT on unknown address 0x2424ee1600107537 (pc 0x7ffff7d0652b bp 0x000000000006 sp 0x7fffffffe0c0 T0)
    #0 0x7ffff7d0652b in __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
    #1 0x7ffff7d0652b in __pthread_kill_internal ./nptl/pthread_kill.c:78:10
    #2 0x7ffff7d0652b in pthread_kill ./nptl/pthread_kill.c:89:10
    #3 0x7ffff7cb13b5 in raise ./signal/../sysdeps/posix/raise.c:26:13
    #4 0x7ffff7c9787b in abort ./stdlib/abort.c:79:7
    #5 0x7ffff7c9779a in __assert_fail_base ./assert/assert.c:92:3
    #6 0x7ffff7ca8b65 in __assert_fail ./assert/assert.c:101:3
    #7 0x5555556d9f2d in signkey_type_from_signature dropbear/consumer/src/signkey.c:186:2
    #8 0x55555576af75 in recv_msg_userauth_pk_ok dropbear/consumer/src/cli-authpubkey.c:69:12
    #9 0x555555747079 in process_packet dropbear/consumer/src/process-packet.c:146:4
    #10 0x555555712204 in session_loop dropbear/consumer/src/common-session.c:254:5
    #11 0x55555575d913 in cli_session dropbear/consumer/src/cli-session.c:134:2
    #12 0x5555557561b7 in main dropbear/consumer/src/cli-main.c:97:2
    #13 0x7ffff7c98a8f in __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #14 0x7ffff7c98b48 in __libc_start_main ./csu/../csu/libc-start.c:360:3
    #15 0x55555558f604 in _start ??:0:0

AddressSanitizer can not provide additional info.

Best,
Nils

[mkj]

Thanks, do you have details what the remote sent to trigger it?

[nbars]

I attached a pcap of the communication causing the error. Also, here is an rr session if you want to look into this more thoroughly.

id:168-dst-port-2255.zip

[mkj]

Thanks, the rr session made it pretty clear. The failure only happens on the client.

I wonder why the existing client fuzzer in oss-fuzz hasn't hit it...

[mkj]

I wonder why the existing client fuzzer in oss-fuzz hasn't hit it...

Aha, it's because the oss-fuzz runs don't have any auth key for the client to use, vs your session's

readhostkey (filename@0x7fffffffea97="/home/user/fuzztruction/fuzztruction-experiments/comparison-with-state-of-the-art/configurations/networked/dropbear/keys/ed25519", hostkey=0x5555558d0c40, type=0x7fffffffe56c) = 0

I'm impressed by rr!