Re: sendmail broken by libssl in current

On 3/10/15 23:57, Julian Elischer wrote: > [sorry for reposting but the original copy I got back had been truncated] > > libssl has a new "feature" > implemented by: > crypto/openssl/ssl/t1_lib.c > > 672 /* Add padding to workaround bugs in F5 terminators. > 673 * See h

Re: sendmail broken by libssl in current

On 3/11/15 12:14 AM, Xin Li wrote: On 3/10/15 23:57, Julian Elischer wrote: [sorry for reposting but the original copy I got back had been truncated] libssl has a new "feature" implemented by: crypto/openssl/ssl/t1_lib.c 672 /* Add padding to workaround bugs in F5 terminators.

Re: DRAM Rowhammer exploits

On 3/9/15 12:49 PM, Dmitry Morozovsky wrote: Dear colleagues, any thoughts we're vulnerable to this? http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html one important part of this exploit is the following part: ---quote--- How can we pick pairs of addresses

Re: sendmail broken by libssl in current

On 11-3-2015 08:58, Julian Elischer wrote: I found I could not talk to my child's school (department of education) and my bank, over a period of just a week.. I will look to see if I start picking up new failures now (and see how many F5 appliances there are :-). If you'd like to have a bit of

sendmail broken by libssl in current

libssl has a new "feature" implemented by: crypto/openssl/ssl/t1_lib.c 672 /* Add padding to workaround bugs in F5 terminators. 673 * See https://tools.ietf.org/html/draft-agl-tls-padding-03 674 * 675 * NB: because this code works out the lengt

Re: sendmail broken by libssl in current

[Forwarded from Greg, before he had to go offline] On Tue, 10 Mar 2015, Julian Elischer wrote: > libssl has a new "feature" > implemented by: > crypto/openssl/ssl/t1_lib.c > > 672 /* Add padding to workaround bugs in F5 terminators. > 673 * See https://tools.ietf.org/htm

Re: sendmail broken by libssl in current

On Mar 10, 2015, at 11:57 PM, Julian Elischer wrote: > unfortunatly this makes sendmail incompatible with various email servers > around the world, > including (apparently (ironically (*))) Ironport email gateways. > It fails in TLS handshake. Can you say which email servers *other* than unpatch

Re: sendmail broken by libssl in current

Paul Hoffman wrote: > Can you say which email servers *other* than unpatched Ironport fail? > Cisco has known about this for many months; see > Note that Bug CSCuo25276 is considered duplicate of the bug CSCuo25329. > If that's true (I can't co

Re: sendmail broken by libssl in current

First, thank you Philip for jumping on this. Much appreciated. > This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in > SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes > SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that > #define exists.

Re: DRAM Rowhammer exploits

On Wed, Mar 11, 2015 at 01:11:25AM -0700, Julian Elischer wrote: > On 3/9/15 12:49 PM, Dmitry Morozovsky wrote: > > Dear colleagues, > > > > any thoughts we're vulnerable to this? > > > > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html > > > one important par

Re: DRAM Rowhammer exploits

On 3/11/2015 2:13 PM, Konstantin Belousov wrote: I just made somewhat dirty port of the double_sided program, available at https://github.com/kostikbel/rowhammer-test/tree/freebsd How many iterations does it usually take to trip up the bug if its there ? ---Mike -- -

Re: DRAM Rowhammer exploits

On Wed, Mar 11, 2015 at 02:30:37PM -0400, Mike Tancsa wrote: > On 3/11/2015 2:13 PM, Konstantin Belousov wrote: > > > I just made somewhat dirty port of the double_sided program, available at > > https://github.com/kostikbel/rowhammer-test/tree/freebsd > > How many iterations does it usually take

Re: sendmail broken by libssl in current

On 3/11/15 7:55 AM, Dan Lukes wrote: Paul Hoffman wrote: Can you say which email servers *other* than unpatched Ironport fail? Cisco has known about this for many months; see Note that Bug CSCuo25276 is considered duplicate of the bug CSCuo253

Re: sendmail broken by libssl in current

On 3/11/15 9:15 AM, Gregory Shapiro wrote: First, thank you Philip for jumping on this. Much appreciated. This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes SSL_OP_TLSEXT_PADDING from the default ClientSSLOpti

Re: sendmail broken by libssl in current

On Mar 11, 2015, at 9:15 AM, Gregory Shapiro wrote: > First, thank you Philip for jumping on this. Much appreciated. > >> This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in >> SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes >> SSL_OP_TLSEXT_PADDING from the

Re: sendmail broken by libssl in current

> > sendmail 8.15.1 is imported into the vendor area but not merged due to an > > incompatible change that is being moved into a run-time configuration > > variable in 8.15.2. Rather than expose the FreeBSD populate to the churn > > from that change, I am skipping 8.15.1 and will import 8.15.2.

Re: sendmail broken by libssl in current

On Mar 11, 2015, at 12:25 PM, Gregory Shapiro wrote: > >>> sendmail 8.15.1 is imported into the vendor area but not merged due to an >>> incompatible change that is being moved into a run-time configuration >>> variable in 8.15.2. Rather than expose the FreeBSD populate to the churn >>> from

Re: sendmail broken by libssl in current

Julian Elischer wrote: >>> Can you say which email servers *other* than unpatched Ironport fail? > well my problem is that I don't know what the other ends are running > exactly, but they are pretty big institution. Just side note - you need not to wait for a source patch. Just disable TLS for th