Re: http://heartbleed.com/
On 10.4.2014, at 15.48, Ed Maste wrote: > On 10 April 2014 06:33, Kimmo Paasiala wrote: >> >> Going back to this original report of the vulnerability. Has it been >> established with certainty that the attacker would first need MITM >> capability to exploit the vulnerability? I'm asking this because MITM >> capability is not something that just any attacker can do. Also if this is >> true then it can be argued that the severity of this vulnerabilty has be >> greatly exaggerated. > > No, the attack does not rely on MITM. The vulnerability is available > to anyone who can establish a connection. Yes of course when you now read the description of the problem at http://heartbleed.com/ it’s completely clear that the attack can be done by anyone. Thanks. -Kimmo signature.asc Description: Message signed with OpenPGP using GPGMail
Re: http://heartbleed.com/
On 10 April 2014 06:33, Kimmo Paasiala wrote: > > Going back to this original report of the vulnerability. Has it been > established with certainty that the attacker would first need MITM capability > to exploit the vulnerability? I'm asking this because MITM capability is not > something that just any attacker can do. Also if this is true then it can be > argued that the severity of this vulnerabilty has be greatly exaggerated. No, the attack does not rely on MITM. The vulnerability is available to anyone who can establish a connection. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On 8.4.2014, at 17.05, Dirk Engling wrote: > On 08.04.14 15:45, Mike Tancsa wrote: > >>I am trying to understand the implications of this bug in the >> context of a vulnerable client, connecting to a server that does not >> have this extension. e.g. a client app linked against 1.xx thats >> vulnerable talking to a server that is running something from RELENG_8 >> in the base (0.9.8.x). Is the server still at risk ? Will the client >> still bleed information ? > > If the adversary is in control of the network and can MITM the > connection, then yes. The client leaks random chunks of up to 64k > memory, and that is for each heartbeat request the server sends. > > erdgeist > Going back to this original report of the vulnerability. Has it been established with certainty that the attacker would first need MITM capability to exploit the vulnerability? I’m asking this because MITM capability is not something that just any attacker can do. Also if this is true then it can be argued that the severity of this vulnerabilty has be greatly exaggerated. -Kimmo signature.asc Description: Message signed with OpenPGP using GPGMail
Re: http://heartbleed.com/
On 4/8/2014 10:09 AM, Merijn Verstraaten wrote: On Apr 8, 2014, at 15:45 , Mike Tancsa wrote: Hi, I am trying to understand the implications of this bug in the context of a vulnerable client, connecting to a server that does not have this extension. e.g. a client app linked against 1.xx thats vulnerable talking to a server that is running something from RELENG_8 in the base (0.9.8.x). Is the server still at risk ? Will the client still bleed information ? ---Mike Information can be bled from a vulnerable OpenSSL talking to a malicious peer (i.e. malicious peer forces heartbeat and bleeds info from the vulnerable app). So no, vulnerable clients can't bleed info from safe servers. More importantly, since the leak only occurs when talking to malicious peers, your clients should be safe if they only communicate with trusted servers (since, presumably, your own servers don't maliciously enable heartbeat and leak info from clients). Of course it's still recommended to update your clients and renew keys, but in practice the risk should be minor for clients that only talk to secure servers. Thanks! Although we are certainly planing to update the vulnerable clients, this is not quite as dire and urgent as first described in the popular press-- at least as it applies to my client base. We also use IP addresses for the target servers in the client configs, so DNS poisoning does not apply to my scenario to trick the clients through that vector. Still, there are other ways, but this reduces the risk somewhat for my scenario at least. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On Apr 8, 2014, at 15:45 , Mike Tancsa wrote: > Hi, > I am trying to understand the implications of this bug in the context > of a vulnerable client, connecting to a server that does not have this > extension. e.g. a client app linked against 1.xx thats vulnerable talking to > a server that is running something from RELENG_8 in the base (0.9.8.x). Is > the server still at risk ? Will the client still bleed information ? > > ---Mike Information can be bled from a vulnerable OpenSSL talking to a malicious peer (i.e. malicious peer forces heartbeat and bleeds info from the vulnerable app). So no, vulnerable clients can't bleed info from safe servers. More importantly, since the leak only occurs when talking to malicious peers, your clients should be safe if they only communicate with trusted servers (since, presumably, your own servers don't maliciously enable heartbeat and leak info from clients). Of course it's still recommended to update your clients and renew keys, but in practice the risk should be minor for clients that only talk to secure servers. Cheers, Merijn signature.asc Description: Message signed with OpenPGP using GPGMail
Re: http://heartbleed.com/
On 08.04.14 15:45, Mike Tancsa wrote: > I am trying to understand the implications of this bug in the > context of a vulnerable client, connecting to a server that does not > have this extension. e.g. a client app linked against 1.xx thats > vulnerable talking to a server that is running something from RELENG_8 > in the base (0.9.8.x). Is the server still at risk ? Will the client > still bleed information ? If the adversary is in control of the network and can MITM the connection, then yes. The client leaks random chunks of up to 64k memory, and that is for each heartbeat request the server sends. erdgeist ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On 4/7/2014 5:02 PM, Xin Li wrote: The implications of this vulnerability are pretty massive, certificates will need to be replaced and so on. I don't want to repeat the page, so go read that. We are already working on this but building, reviewing, etc. would take some time. Attached is the minimal fix (extracted from upstream git repository) we are intending to use in the advisory for those who want to apply a fix now, please DO NOT use any new certificates before applying fixes. Hi, I am trying to understand the implications of this bug in the context of a vulnerable client, connecting to a server that does not have this extension. e.g. a client app linked against 1.xx thats vulnerable talking to a server that is running something from RELENG_8 in the base (0.9.8.x). Is the server still at risk ? Will the client still bleed information ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On 4/7/2014 3:49 PM, Thomas Steen Rasmussen wrote: > Hello, > > http://heartbleed.com/ describes an openssl vulnerability published > today. We are going to need an advisory for the openssl in base in > FreeBSD 10 and we are also going to need an updated port. > > The implications of this vulnerability are pretty massive, > certificates will need to be replaced and so on. I don't want to > repeat the page, so go read that. > > Best regards, > > > /Thomas Steen Rasmussen > > ps. there is a bit on the openssl site too: > https://www.openssl.org/news/secadv_20140407.txt The port has been updated. 1.0.1_10 has the fix. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: http://heartbleed.com/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 4/7/14, 7:27 PM, Mike Tancsa wrote: > On 4/7/2014 5:02 PM, Xin Li wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >> >> Hi, Thomas, >> >> On 04/07/14 13:49, Thomas Steen Rasmussen wrote: >>> Hello, >>> >>> http://heartbleed.com/ describes an openssl vulnerability >>> published today. We are going to need an advisory for the >>> openssl in base in FreeBSD 10 and we are also going to need an >>> updated port. >>> >>> The implications of this vulnerability are pretty massive, >>> certificates will need to be replaced and so on. I don't want >>> to repeat the page, so go read that. >> >> We are already working on this but building, reviewing, etc. >> would take some time. >> > > Hi, The webpage lists > > FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c) > > I take it this is only if you installed from the ports no ? That's correct. OpenSSL shipped with the base system in these two releases are not vulnerable because they don't support the extension. Cheers, -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTQ179AAoJEJW2GBstM+nsIa4P/RAXDidWzc01T2ghX4uNFtod C2Wd2k2B6i24LcV3PPub6dQjRI9sMxh9Q/7bIqXctThJ41U9s44P7Zvf6T7Xh/LY YM4FBAFKNiMC+WZsS78pGW6pYIULml66El7sb/G6DNOzjezWlD3MwnPo2S0nibQJ BDJ0pU3BH0A2rvyDWmF7aAveJtEuFPCCovytadStHiFZk3nKMwdN0ariLVq8JFlU s5uqf0rWRXuYIIJ2/Fv9XxUHWi0RrvyXojfdPVNIhEppmdswCzxyb+PLOBbWuZZp 9ma/ELuo8VJmmsP2A0zX2PriejfFtTR7vXP8V3VwP8RvS2YRFH44Bmyllxn2eYYI HbemABH2A5rCiMbEu32AGX7i1HikWScwKNIEJbK35BEIb9g3UGRFuxeRw9J6mTyd 44hMRO1YeyHv/nuSQ+g+d+nzB1dBYSq7YbG5UAPs0v+5fbnoPTU/28olKx1br83H BZdO+y8VUppNnRWL2wvnsbd1M8/nGABNBD9tco9ftlN0jUpFtSXkPEt20JWwZS/l HiD328EnTJKgB5nllizsCDIgaTDUYMeH6Bf8QJ54t+Cfu6sS1YYCv2/ycu5tKfqv yRU6ypV82kye/fRBkFj4JwCOXcPozm+9uPAG9bk1355w+EyKmMrba79BvwtQ+uUj PXJpfmZifPnNDBTXrg2d =FDDO -END PGP SIGNATURE- ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On 4/7/2014 5:02 PM, Xin Li wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Thomas, On 04/07/14 13:49, Thomas Steen Rasmussen wrote: Hello, http://heartbleed.com/ describes an openssl vulnerability published today. We are going to need an advisory for the openssl in base in FreeBSD 10 and we are also going to need an updated port. The implications of this vulnerability are pretty massive, certificates will need to be replaced and so on. I don't want to repeat the page, so go read that. We are already working on this but building, reviewing, etc. would take some time. Hi, The webpage lists FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c) I take it this is only if you installed from the ports no ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi, Thomas,
On 04/07/14 13:49, Thomas Steen Rasmussen wrote:
> Hello,
>
> http://heartbleed.com/ describes an openssl vulnerability
> published today. We are going to need an advisory for the openssl
> in base in FreeBSD 10 and we are also going to need an updated
> port.
>
> The implications of this vulnerability are pretty massive,
> certificates will need to be replaced and so on. I don't want to
> repeat the page, so go read that.
We are already working on this but building, reviewing, etc. would
take some time.
Attached is the minimal fix (extracted from upstream git repository)
we are intending to use in the advisory for those who want to apply a
fix now, please DO NOT use any new certificates before applying fixes.
Cheers,
- --
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)
iQIcBAEBCgAGBQJTQxJ1AAoJEJW2GBstM+nsz6AP/2m28eIzuF/JFhyZB7rkLAZR
vP9P0Tu1Vupwd6FN5X9m1O4t5ORhMfn5Y8SuxemHPg8NncaEptg43rs+TED4ucGd
ulyFLJsAZtCDlTTVRAuhp3PfvNllBcoG6a+sWg0qjDqxnzWpPZShCP8ay9g/3q4W
ceYJigXyi7KtKuNlc2YXlC5CA5NpKV9zsc0KhZj/PIq9qLiv+JYUriz1BRE8J+5P
CusO3usNgwHFx0XppMQRXxg/iSYnqs/YM6btENgsOBlRsCJkfSPbxE1z6Vmp0h27
mOWiBLIOOR97WfYHCUHUHg+1bpJKz6VXUDHbNjjoaaLWg2D4HCkqgm45mgKZBHwh
6SZUR90WthBbbFwJ3vY+wdARBO1V3RBg64ACZfYEIimqtGKZ5VaJgmYFLZc33RQr
O6Gpt7KeiwxaPYe/18zIiBULKeGBtQXettKpw4KOrkKSfnZePNxQIiqQmzLmfzXW
VwgRYlAAhjmv/ROCdnQJiKQKnloo9xUEPtk1ngmw6ThJJuDGS+Mcm1pWwbvMPF5/
cWXprDXW4/Hws8GCXbZxYRrC0xQ0zDL+K589H/3pTWV5ijnI/CpM1gzvd0NH/H4+
LQNILNJ+p2Uhp3D7yoz1bQC8gV2XeXROeNGEuY3VRyNbnv3z65mjWry/4QZo+kp6
NcKVrUpKLG4odhL7BXBF
=7rU5
-END PGP SIGNATURE-
Index: crypto/openssl/ssl/d1_both.c
===
--- crypto/openssl/ssl/d1_both.c(revision 264059)
+++ crypto/openssl/ssl/d1_both.c(working copy)
@@ -1458,26 +1458,36 @@ dtls1_process_heartbeat(SSL *s)
unsigned int payload;
unsigned int padding = 16; /* Use minimum padding */
+ if (s->msg_callback)
+ s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT,
+ &s->s3->rrec.data[0], s->s3->rrec.length,
+ s, s->msg_callback_arg);
+
/* Read type and payload length first */
+ if (1 + 2 + 16 > s->s3->rrec.length)
+ return 0; /* silently discard */
hbtype = *p++;
n2s(p, payload);
+ if (1 + 2 + payload + 16 > s->s3->rrec.length)
+ return 0; /* silently discard per RFC 6520 sec. 4 */
pl = p;
- if (s->msg_callback)
- s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT,
- &s->s3->rrec.data[0], s->s3->rrec.length,
- s, s->msg_callback_arg);
-
if (hbtype == TLS1_HB_REQUEST)
{
unsigned char *buffer, *bp;
+ unsigned int write_length = 1 /* heartbeat type */ +
+ 2 /* heartbeat length */ +
+ payload + padding;
int r;
+ if (write_length > SSL3_RT_MAX_PLAIN_LENGTH)
+ return 0;
+
/* Allocate memory for the response, size is 1 byte
* message type, plus 2 bytes payload length, plus
* payload, plus padding
*/
- buffer = OPENSSL_malloc(1 + 2 + payload + padding);
+ buffer = OPENSSL_malloc(write_length);
bp = buffer;
/* Enter response type, length and copy payload */
@@ -1488,11 +1498,11 @@ dtls1_process_heartbeat(SSL *s)
/* Random padding */
RAND_pseudo_bytes(bp, padding);
- r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload
+ padding);
+ r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer,
write_length);
if (r >= 0 && s->msg_callback)
s->msg_callback(1, s->version, TLS1_RT_HEARTBEAT,
- buffer, 3 + payload + padding,
+ buffer, write_length,
s, s->msg_callback_arg);
OPENSSL_free(buffer);
Index: crypto/openssl/ssl/t1_lib.c
===
--- crypto/openssl/ssl/t1_lib.c (revision 264059)
+++ crypto/openssl/ssl/t1_lib.c (working copy)
@@ -2486,16 +2486,20 @@ tls1_process_heartbeat(SSL *s)
unsigned int payload;
unsigned int padding = 16; /* Use minimum padding */
+ if (s->msg_callback)
+ s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT,
+ &s->s3->rrec.data[
http://heartbleed.com/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, http://heartbleed.com/ describes an openssl vulnerability published today. We are going to need an advisory for the openssl in base in FreeBSD 10 and we are also going to need an updated port. The implications of this vulnerability are pretty massive, certificates will need to be replaced and so on. I don't want to repeat the page, so go read that. Best regards, /Thomas Steen Rasmussen ps. there is a bit on the openssl site too: https://www.openssl.org/news/secadv_20140407.txt -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQw9yAAoJEHcv938JcvpYcFgP/iH3j6n7PgkCwSsN3qG9F37c A6TOGbKudIeJdO76YXiU2T+FjbMThB86KuSan2iTM4h5wTLENVLvafJmBJtIKRH8 bMZUqsUONYBSd4HpZKxbg9s8Yfy2gU0dTbs10OZ/dZw6qEr5Pd0WK6BDZ5h0ggTj 0gF4r+FHWAe/8GgxOnfVEcmyMa+VUB46ZMmpwlCC3SG0wMAs/LJHORyl283OqyT5 fwNfeDjInsPAgZORdR2+PZTgshwL0ogOINyGSKrLV1psQg2hEMgRT4GvO37IlhHS qstYleB0yLiq9ayRFyj3mg2/OMq7/26ft09fHeF19VjnysClxT7lwZEaPDkbxH7j qC1rpo1yeGuBPPdFnjbZVP5rxLR1jnQZFgTwOafjjock8ZW1ktUXOg1Upe276sv9 NrPmNzDUkuMp7tlYEuDC2MsxQNSjeCo86FdMGCH+/c+DbRqBidELFH8SYEgzK2kj TiT8tmBjdLC8PL+1SvBV4hLgapFJp2nvXsxyuJc2teRntKdgjFObQPEzb+iM/zFA mSOjuGUh28qABlqQ32B04VDBOQRUs6zWDe0cssspajqfx7T7wVaE1FGBDUUt0QkN B45cs2ql0OG5XB03GLsJv0tSdymzwohlBmoqmA08mKVWILFdkL/zzSY8Mw0oTfUa GWD5kOI/wytuF5svXFnP =gj4I -END PGP SIGNATURE- ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
