Heartbleed test vsftp with STARTTLS false positive

[thomaspatzke]

The test for Heartbleed caused a false positive. After sending the payload the server answers with:

00000000  35 30 30 20 4f 4f 50 53  3a 20 65 72 72 6f 72 3a  |500 OOPS: error:|
00000010  30 30 30 30 30 30 30 30  3a 6c 69 62 28 30 29 3a  |00000000:lib(0):|
00000020  66 75 6e 63 28 30 29 3a  72 65 61 73 6f 6e 28 30  |func(0):reason(0|
00000030  29 0d 0a 35 30 30 20 4f  4f 50 53 3a 20 63 68 69  |)..500 OOPS: chi|
00000040  6c 64 20 64 69 65 64 0d  0a                       |ld died..|

This is an error from the FTP server itself, not leaked memory content.

Environment: vsFTPd 2.2.2 - further details unknown

[drwetter]

Hi Thomas,

I don't think testssl.sh can ever have the intelligence to tell this apart, unless somebody volunteers to implement KI in bash (btw: do I also see hands rising for ASN1 parser in bash ;-) )

Remarkable though that testssl.sh caused an oops in the very secure ftpd...

Cheers , Dirk

[drwetter]

I misunderstood this, sorry.

vsftpd's standard behavior is "oops" if a setting is during runtime not compatible with a command. It's not a program failure as I assumed.

I was just able to reproduce this.

Seems that after the AUTH TLS it is getting the certificate it correctly switched to the TLS layer. It replies plaintext (see above also) though after sending the payload:

 Testing vulnerabilities 

 Heartbleed (CVE-2014-0160)                === just read banner ===
220 (vsFTPd 3.0.2)

=== sending "FEAT" ...
... received result: 
211-Features:
 AUTH TLS
 EPRT
 EPSV
 MDTM
 PASV
 PBSZ
 PROT
 REST STREAM
 SIZE
 TVFS
211 End
---> reply matched "211"

=== sending "FEAT" ...

=== sending "AUTH TLS" ...
... received result: 
211-Features:
 AUTH TLS
 EPRT
 EPSV
 MDTM
 PASV
 PBSZ
 PROT
 REST STREAM
 SIZE
 TVFS
211 End
234 Proceed with negotiation.
---> reply matched "successful|234"

sending client hello (TLS version x03, x03)
"\x16\x03\x01\x00\xdc\x01\x00\x00\xd8\x03\x03\x53\x43\x5b\x90\x9d\x9b\x72\x0b\xbc\x0c\xbc\x2b\x92\xa8\x48\x97\xcf\xbd\x39\x04\xcc\x16\x0a\x85\x03\x90\x9f\x77\x04\x33\xd4\xde\x00\x00\x66\xc0\x14\xc0\x0a\xc0\x22\xc0\x21\x00\x39\x00\x38\x00\x88\x00\x87\xc0\x0f\xc0\x05\x00\x35\x00\x84\xc0\x12\xc0\x08\xc0\x1c\xc0\x1b\x00\x16\x00\x13\xc0\x0d\xc0\x03\x00\x0a\xc0\x13\xc0\x09\xc0\x1f\xc0\x1e\x00\x33\x00\x32\x00\x9a\x00\x99\x00\x45\x00\x44\xc0\x0e\xc0\x04\x00\x2f\x00\x96\x00\x41\xc0\x11\xc0\x07\xc0\x0c\xc0\x02\x00\x05\x00\x04\x00\x15\x00\x12\x00\x09\x00\x14\x00\x11\x00\x08\x00\x06\x00\x03\x00\xff\x01\x00\x00\x49\x00\x0b\x00\x04\x03\x00\x01\x02\x00\x0a\x00\x34\x00\x32\x00\x0e\x00\x0d\x00\x19\x00\x0b\x00\x0c\x00\x18\x00\x09\x00\x0a\x00\x16\x00\x17\x00\x08\x00\x06\x00\x07\x00\x14\x00\x15\x00\x04\x00\x05\x00\x12\x00\x13\x00\x01\x00\x02\x00\x03\x00\x0f\x00\x10\x00\x11\x00\x23\x00\x00\x00\x0f\x00\x01\x01"

reading server hello
00000000  16 03 03 3a 02 36 03 03  d4 ee 11 45 d3 63 a8 f1  |...:.6.....E.c..|
{some redacted output of the certificate}
00000110  61 6d 62 75 72 67 31 10  30 0e 06 03 55 04 07 0c  |amburg1.0...U...|
00000120  07 48 61 6d 62 75 72 67  31 21 30 1f 06 03 55 04  |.Hamburg1!0...U.|
00000130  {more redacted output of the certificate}
[...]

sending payload with TLS version x03, x03:
"\x18\x03\x03\x00\x03\x01\x40\x00"

heartbleed reply: 
00000000  35 30 30 20 4f 4f 50 53  3a 20 65 72 72 6f 72 3a  |500 OOPS: error:|
00000010  30 30 30 30 30 30 30 30  3a 6c 69 62 28 30 29 3a  |00000000:lib(0):|
00000020  66 75 6e 63 28 30 29 3a  72 65 61 73 6f 6e 28 30  |func(0):reason(0|
00000030  29 0d 0a                                          |)..|
00000033

VULNERABLE (NOT ok)

That's a tough one, need to sleep over it. First thing which comes to mind is checking for 500 OOPS but it feels more like a last resort to me.

[drwetter]

Btw: Thx for reporting, @thomaspatzke

[thomaspatzke]

Another idea for a heuristic: run the test multiple times. A service vulnerable to heartbleed would quite certain give different responses while the response in this case was always equal.

[drwetter]

Good idea, thx!

We're the results EXACTLY the same?

Sent from my mobile. Excuse my brevity&typos+the phone's autocorrection

[thomaspatzke]

Yes! Tested it few times, message seems to be static.

[drwetter]

Good idea, I thought too that would suffice. ;-/

Catch is a vulnerable, idle server. Here I get exacltly the same memory returned a couple of times. And as if the server wanted to tease me, one readable string in all that binary blurp was "42" ;-)

.

[drwetter]

Hi Thomas,

on my installation the recent commit works as expected and seems robust -- also on the idle server. There's just another check to make sure. Could you please double check?

Thx, Dirk