Skip Menu |
 
Ticket metadata
The Basics
Id: 2975
Status: resolved
Priority: 0/
Queue: OpenSSL-Bugs

Custom Fields
Milestone: (no value)
Subsystem: (no value)
Severity: (no value)
Broken in: (no value)

People
Owner: Nobody in particular
Requestors: Kris Karas
Cc:
AdminCc:

More about the requestors

Kris Karas

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Everyone
  • Unprivileged

New reminder:
Subject:
Owner:
Due:

Dates
Created: Wed Feb 06 23:01:25 2013
Starts: Not set
Started: Thu Feb 07 00:43:10 2013
Last Contact: Thu Feb 07 22:22:24 2013
Due: Not set
Closed: Mon Mar 18 21:39:24 2013
Updated: Mon Mar 18 21:39:24 2013 by Andy Polyakov



Subject: [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream
Date: Wed, 06 Feb 2013 14:50:55 -0500
To: rt@openssl.org
From: Kris Karas <bugs-a12@moonlit-rail.com>
Download (untitled) / with headers
text/plain 3.2k
A serious regression was introduced in 1.0.1d that corrupts the data
stream under certain circumstances.

Firefox requests to an Apache server running on Linux/X86_64 with
OpenSSL-1.0.1d result in "501 Server Error" responses. OpenSSL versions
1.0.1c and earlier are not affected. i686 (32 bit) versions are also
not affected.

An excerpt from the Apache log with 1.0.1c, showing correct behavior:

10.1.2.3 - - [05/Feb/2013:23:06:59 -0500] "GET / HTTP/1.1" 200 203 "-" "Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0"
10.1.2.3 - - [05/Feb/2013:23:30:39 -0500] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0"

An excerpt from the Apache log with 1.0.1d, clearly showing the invalid
request:

10.1.2.3 - - [05/Feb/2013:22:47:02 -0500] "G\xedET / HTTP/1.1" 501 932 "-" "Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0"
10.1.2.3 - - [05/Feb/2013:23:04:03 -0500] "G<ET / HTTP/1.1" 501 932 "-" "Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0"


A look at the ssl-request log from Apache is also interesting, as
Firefox sees corruption (first log line) but Links (text-based web
browser, second log line) does not. This hints at it being cipher-specific:

10.1.2.3 TLSv1 ECDHE-RSA-AES256-SHA "G\xedET / HTTP/1.1" 932
10.1.2.3 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "GET / HTTP/1.1" 203

I haven't had a chance (yet?) to bisect the code to find the culprit,
but I can take a stab at it if a developer doesn't know off the top of
their head just where it might be.

The OS here is Slackware-64. Compiler is gcc-4.7.2, binutils
2.23.51.0.6, glibc 2.15.
A portion of the output of configure is:

Configuring for linux-x86_64
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-sctp [default] OPENSSL_NO_SCTP (skip dir)
no-store [experimental] OPENSSL_NO_STORE (skip dir)
IsMK1MF=0
CC =gcc
CFLAG =-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
EX_LIBS =-ldl
CPUID_OBJ =x86_64cpuid.o
BN_ASM =x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o modexp512-x86_64.o
DES_ENC =des_enc.o fcrypt_b.o
AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o
BF_ENC =bf_enc.o
CAST_ENC =c_enc.o
RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC =rc5_enc.o
MD5_OBJ_ASM =md5-x86_64.o
SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC =cmll-x86_64.o cmll_misc.o
MODES_OBJ =ghash-x86_64.o
ENGINES_OBJ =
PROCESSOR =
RANLIB =/usr/bin/ranlib
ARFLAGS =
PERL =/usr/bin/perl
SIXTY_FOUR_BIT_LONG mode
DES_UNROLL used
DES_INT used
RC4_CHUNK is unsigned long


Best regards,
Kris Karas
On Wed Feb 06 23:01:25 2013, bugs-a12@moonlit-rail.com wrote:
Show quoted text
>
> I haven't had a chance (yet?) to bisect the code to find the culprit,
> but I can take a stab at it if a developer doesn't know off the top of
> their head just where it might be.
>

Stop gap measure for now is to revert commit 125093b59f3c

We're looking into the proper fix.

Steve.
-- 
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
On Thu Feb 07 00:43:10 2013, steve wrote:
Show quoted text
> On Wed Feb 06 23:01:25 2013, bugs-a12@moonlit-rail.com wrote:
> >
> > I haven't had a chance (yet?) to bisect the code to find the culprit,
> > but I can take a stab at it if a developer doesn't know off the top of
> > their head just where it might be.
> >
>
> Stop gap measure for now is to revert commit 125093b59f3c
>

Please see if commit  32cc247 fixes this:

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247

It will also appear in the next snapshot of OpenSSL 1.0.1.

If it does and there are no more reports of serious problems in 1.0.1d we'll roll another release.

Steve.
-- 
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
CC: openssl-dev@openssl.org
Subject: Re: [openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream
Date: Fri, 08 Feb 2013 11:06:43 -0500
To: rt@openssl.org
From: Kris Karas <bugs-a12@moonlit-rail.com>
Download (untitled) / with headers
text/plain 1.1k
Stephen Henson via RT wrote:
Show quoted text
> Please see if commit 32cc247 fixes this:
>
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247

Confirmed! "Works for me." (But, see P.S., below.)

I re-confirmed the error was repeatably reproducible.
Applied the patch, and was no longer able to reproduce the error.
Reverse-applied the patch, and the error instantly returned.

The patch does indeed do the right thing in this case.
Thank you!

Kris

P.S. Was supposed to work from home today due to potentially worst snow
in Boston in 35 years. But I could not reproduce the error in this
report on my server at home, despite many recompiles of related things
into the wee hours. I'm perplexed as to what the difference could be.
Same OS, same libraries, at least for Apache and related. Work system
is Core-i7 and home is Athlon-II. Did a diff between the output of
"Configure" of both systems and it is identical. (Certificates?) I'll
try pushing the binary package at work to home and see if that makes any
difference. Ergo, by virtue of the difficulty in reproducing this bug,
it might not affect as many people as I first thought.