Closed bjmgeek closed 3 years ago
This appears to be related to the internal checks. If I use --ssl-native
it doesn't crash.
according to git bisect
:
0676866e91d7b0499e59ed97553f22729bca7f15 is the first bad commit
Hi @bjmgeek ,
thanks.
Likely internal checks have nothing to do with it, it's an internal conversion function which hiccups on the input. However I can't tell what the input is as 7f071dd is rather old and the line 14165 has no meaning to me.
Could you do a git pull and run again (--freak should suffice)?
Cheers, Dirk
PS: Can't follow you why you think 0676866 is the bad commit? That one is really old (2016 from @dcooper16 ).
I just did a git bisect. I agree that's really old. I may have done it wrong. I'll try it with --freak.
On Mon, Oct 26, 2020 at 12:59 PM Dirk Wetter notifications@github.com wrote:
Hi @bjmgeek https://github.com/bjmgeek ,
thanks.
Likely internal checks have nothing to do with it, it's an internal conversion function which hiccups on the input. However I can't tell what the input is as 7f071dd https://github.com/drwetter/testssl.sh/commit/7f071ddbb95b322d044535ba91c18ca73c8e8c2c is rather old and the line 14165 has no meaning to me.
Could you do a git pull and run again (--freak should suffice)?
Cheers, Dirk
PS: Can't follow you why you think 0676866 https://github.com/drwetter/testssl.sh/commit/0676866e91d7b0499e59ed97553f22729bca7f15 is the bad commit? That one is really old (2016 from @dcooper16 https://github.com/dcooper16 ).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/drwetter/testssl.sh/issues/1754#issuecomment-716687299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADQJ3NLA4BY336X3GYGZV3SMWTFZANCNFSM4S7NUGEA .
Given the date for commit https://github.com/drwetter/testssl.sh/commit/0676866e91d7b0499e59ed97553f22729bca7f15, I was able to figure out what was at line 14165. It is in `sslv2_sockets():
sockread_serverhello 32768
if "$parse_complete"; then
server_hello=$(hexdump -v -e '16/1 "%02X"' "$SOCK_REPLY_FILE")
server_hello_len=2+$(hex2dec "${server_hello:1:3}")
Presumably, hex2dec()
doesn't like the input it is being provided and so it complains that "16#: invalid integer constant (error token is "16#")". Then, line 14165 complains because it can't add "2" and whatever hex2dec()
returned.
However, I tried running echo $((16#$1))
with different inputs and couldn't replicate the error message.
What might be helpful would be see a debug output of the run so that we can see what $server_hello looks like when hex2dec()
is called.
As https://github.com/drwetter/testssl.sh/wiki/Findings-and-HowTo-Fix-them notes, you can set a debug output in one of two ways:
2a) For a full debug output
In either case, the debug output shows each line of code as it is being executed, including line numbers. So, in the debug output look for the line that begins "14165>" that shows the error occurring and then copy here that lines and enough of the lines that precede it so that the value of $server_hello
can be seen.
echo $((16#$1))
exit with invalid integer constant
for unset or empty $1
.
Indeed, on my side, echo "$server_hello"
is empty, and cat "$SOCK_REPLY_FILE"
is empty.
From my log, I get a handshake failure
:~$ testssl --debug 6 -F fastmail.com
[...]
FREAK (CVE-2015-0204)
sending client hello... sending client hello...
"\x16\x03\x01\x00\x8b\x01\x00\x00\x87\x03\x03\x54\x51\x1e\x7a\xde\xad\xbe\xef\x31\x33\x07\x00\x00\x00\x00\x00\xcf\xbd\x39\x04\xcc\x16\x0b\x85\x03\x90\x9f\x77\x04\x33\xd4\xde\x00\x00\x14\x00\x62\x00\x61\x00\x64\x00\x60\x00\x14\x00\x0e\x00\x08\x00\x06\x00\x03\x00\xff\x01\x00\x00\x4a\x00\x00\x00\x11\x00\x0f\x00\x00\x0c\x66\x61\x73\x74\x6d\x61\x69\x6c\x2e\x63\x6f\x6d\x00\x23\x00\x00\x33\x74\x00\x00\x00\x0d\x00\x24\x00\x22\x06\x01\x06\x02\x06\x03\x05\x01\x05\x02\x05\x03\x04\x01\x04\x02\x04\x03\x03\x01\x03\x02\x03\x03\x02\x01\x02\x02\x02\x03\x08\x07\x08\x08\x00\x0f\x00\x01\x01"
reading server hello...
00000000 15 03 03 00 02 02 28 |......(|
00000007
15030300020228
TLS message fragments:
protocol (rec. layer): 0x0303
tls_content_type: 0x15 (alert)
msg_len: 2
TLS alert messages:
tls_err_descr_no: 0x28 / = 40 (handshake failure)
tls_err_level: 02 (fatal)
(2 lines returned)
sending client hello...
"\x80\x22\x01\x00\x02\x00\x09\x00\x00\x00\x10\x04\x00\x80\x02\x00\x80\x00\x00\x00\x29\x22\xbe\xb3\x5a\x01\x8b\x04\xfe\x5f\x80\x03\xa0\x13\xeb\xc4"
/usr/bin/testssl: line 1169: 16#: invalid integer constant (error token is "16#")
/usr/bin/testssl: line 12828: 2+: syntax error: operand expected (error token is "+")
@f380cedric I can't reproduce that with the latest and greatest 3.1dev. Which version are you running?
In your version it seems there's a problem parsing the sslv2 response
Tried both 3.0.2 and 3.1dev.
L1169 doesn't make sense in the latest 3.1dev. Could you do a git pull please?
Linux 64bit, bash5.
Yeah, sorry, I mixed 3.0.2 and 3.1dev output in my comment (everything but hello payload are from 3.0.2). Anyway, there is the full output on 3.1dev https://paste.debian.net/1168838
Thanks, I see the problem in the legacy code but still I can't reproduce it.
What does the following return?
bash --version
cat /etc/os-release
?
Note to self: if this is fixed sslv2_sockets should only be invoked when SSLv2 is not available or when not sure when it is a/v.
GNU bash, version 5.1.0(1)-rc1 (x86_64-pc-linux-gnu)
PRETTY_NAME="Debian GNU/Linux bullseye/sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
Versions of packages testssl.sh depends on: bind9-dnsutils [dnsutils] 1:9.16.6-3 bsdextrautils 2.36-3+b1 bsdmainutils 12.1.7 dnsutils 1:9.16.6-3 openssl 1.1.1g-1 procps 2:3.3.16-5
takes a while as I don't have that OS yet.
@bjmgeek : what OS do you run?
Thanks for the input. Fixed for 3.1dev. 3.0 will follow once Travis runs ok
Please make sure that you provide enough information so that we understand what your issue is about.
Did you check the documentation in ~/doc/ or, if it is a different problem: Did you google for it? yes
uname -a Linux laptop 5.5.0 #1 SMP Mon Jan 27 15:00:34 EST 2020 x86_64 GNU/Linux
testssl version from the banner: testssl.sh -b 2>/dev/null | head -4 | tail -2 testssl.sh 3.1dev from https://testssl.sh/dev/
git log | head -1 (if running from git repo) commit 7f071ddbb95b322d044535ba91c18ca73c8e8c2c
openssl version used by testssl.sh: testssl.sh -b 2>/dev/null | awk -F':' '/openssl/ { print $2}' /home/bminton/src/testssl.sh/bin/openssl.Linux.x86_64
steps to reproduce: testssl.sh or docker command line, if possible incl. host testssh.sh https://pure2.example.com (note, this is an internal host, but with a valid certificate)
what exactly was happening, output is needed