headers
Bhanu P Tholeti via RT | 2 Mar 2009 10:55
Picon
Favicon

Re: [openssl.org #1850] AutoReply: Bug Report--openssl crashes at SSL_write()

Hi,
Request for an Update on this issue.  Request for a high priority check on
the same. Will provide additional information if needed.

Thanks & Regards,
BhanuPrakash.T

                                                                           
             "The default                                                  
             queue via RT"                                                 
             <rt <at> openssl.org>                                           To 
                                       Bhanu P Tholeti/India/IBM <at> IBMIN     
             26/02/2009 01:04                                           cc 

                                                                   Subject 
             Please respond to         [openssl.org #1850] AutoReply: Bug  
              rt <at> openssl.org           Report--openssl crashes at          
                                       SSL_write()                         

Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
             "Bug Report--openssl crashes at SSL_write()",
a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been
assigned an ID of [openssl.org #1850].

Please include the string:
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Schwartz | 2 Mar 2009 13:47
Favicon
Gravatar

RE: [openssl.org #1850] AutoReply: Bug Report--openssl crashes at SSL_write()


> Hi,
> Request for an Update on this issue.  Request for a high priority check on
> the same. Will provide additional information if needed.

You could start with:

1) The code around the line of code in SSL_write that fails.

2) Identifying the exact line in SSL_write that fails.

3) The contents of the objects that line references.

4) The parameters to SSL_write.

> #0  0xc0000000125ed640:0 in SSL_write () at ssl_lib.c:866

No parameters, no line of code. Sure, some people could dig out the exact version of OpenSSL that you used and
check that line, but that significantly reduces the number of people who can help you.

> #1  0xc0000000125c5620:0 in HTTPSSLChannel::WriteToSocket (
>     this=0x60000000000e0880,
>     psTxBuffer=0x8003ffffffff15a0 "C_100323\"><!-- Follow dependecies
> --></predecessor>\n</dependencies>\n</job>\n\n\t\t\t<job
> name=\"L21FTPMUBR_KBC_150987\"
> definition=\"jd=P97209023#L21FTPMUBR_KBC_150987\" confirmed=\"False\"
> isKey=\"False\" priori"..., iSize=3911)
>     at
> ../../../../../../src/weblib/wscc/transport/axis3/HTTPSSLChannel/H
> TTPSSLChannel.cpp:773
(Continue reading)

Permalink | Reply | 0 comments |
headers
neorom | 2 Mar 2009 17:15
Picon

Re: help in edsa functions

I resolved my previous problem, the error came in the name of the
variable "key" which has to be named "eckey". So there is a mistake in
the code in the documentation.

Now my problem is more difficult, because after :

Initialization of the structure :
EC_KEY    *eckey =  EC_KEY_new()
link with an elliptic curve :
eckey = EC_GROUP_new_by_curve_name(NID_secp192k1);
finally, the creation of this key :
if (!EC_KEY_generate_key(eckey))
       {
        printf("error key generation\n");
       }

when I execute my code, I get a Semgentation Fault and gdb tell me
that the problem comes with the  function :  BN_copy()

Program received signal SIGSEGV, Segmentation fault.
0x0805fee8 in BN_copy ()

I am working with ubuntu and the libssl0.9.8g-10

Thanks in advance for your help,

Romain Hinfray

On Mon, Mar 2, 2009 at 2:57 PM, neorom <neorom <at> gmail.com> wrote:
> Hello every body,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tanguy Fautré | 2 Mar 2009 17:56
Picon
Favicon

RAND_poll() and CreateToolhelp32Snapshot() stability

Hi,

We've been observing in our application several crashes on Windows related to RAND_poll(). We've been
working on this issue for 3 days now, and came up with a possible explanation and fix. Bare with me on this
rather lengthy email, as I'll try to document as best I can everything we've done and come up with.

The crash (an access violation, usually -but not always- a null pointer) always happens in Heap32Next().

Because RAND_poll uses Heap32Next to traverse through the heaps, our first assessment was that this
function is not thread safe and would leave RAND_poll traversing through garbage data, causing an access
violation. After some googling, several old posts on openssl mailing lists appeared to confirm our
initial fear that RAND_poll implementation is not thread-safe.

However, this does not seem to be a valid explanation. RAND_poll uses CreateToolhelp32Snapshot to create
a snapshot of the heap list; snapshot that is supposedly safe.

<Quote from MSDN>
Snapshots are at the core of the tool help functions. A snapshot is a read-only copy of the current state of
one or more of the following lists that reside in system memory: processes, threads, modules, and heaps.

Processes that use tool help functions access these lists from snapshots instead of directly from the
operating system. The lists in system memory change when processes are started and ended, threads are
created and destroyed, executable modules are loaded and unloaded from system memory, and heaps are
created and destroyed. The use of information from a snapshot prevents inconsistencies. Otherwise,
changes to a list could possibly cause a thread to incorrectly traverse the list or cause an access
violation (a GP fault). For example, if an application traverses the thread list while other threads are
created or terminated, information that the application is using to traverse the thread list might
become outdated and could cause an error for the application traversing the list.
</Quote from MSDN>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Kurt Roeckx | 2 Mar 2009 20:08
Picon

CVE-2009-0653

Can some comment on this:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0653

Is this still a problem in 0.9.8 versions?

Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 2 comments |
headers
Jeff Wu via RT | 2 Mar 2009 19:22
Picon
Favicon

Re: [openssl.org #1851] [PATCH] "openssl verify -CAfile mutil_ca.pem site.cert" fails even if mutil_ca.pem contains the chain for site.cert

Hi, Steve

Thanks for quick response. Since the function (X509_NAME_cmp) is used
for sort and bsearh, we'd better make sure the return value is
consistent. say a>b and b>c, then a>c is always expected. My previous
patch has a clear logic to guarantee this but I am not sure if the fix
in current snapshot also has the same consistence. It works with the
test CA files though.

Regards,

Jeff

On Fri, Feb 27, 2009 at 3:26 PM, Stephen Henson via RT <rt <at> openssl.org> wrote:
>
> Please try this against a recent snapshot of 0.9.8-stable. An update to
> X509_NAME_cmp which was applied recently should address this.
>
> Steve.
>
>
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 0 comments |
headers
Dr. Stephen Henson | 2 Mar 2009 21:46
Picon
Favicon

Re: CVE-2009-0653

On Mon, Mar 02, 2009, Kurt Roeckx wrote:

> Can some comment on this:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0653
> 
> Is this still a problem in 0.9.8 versions?
> 

It was addressed in OpenSSL 0.9.5.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 1 comment |
headers
Kurt Roeckx | 2 Mar 2009 22:56
Picon

Re: CVE-2009-0653

On Mon, Mar 02, 2009 at 09:46:55PM +0100, Dr. Stephen Henson wrote:
> On Mon, Mar 02, 2009, Kurt Roeckx wrote:
> 
> > Can some comment on this:
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0653
> > 
> > Is this still a problem in 0.9.8 versions?
> > 
> 
> It was addressed in OpenSSL 0.9.5.

I assume there was some typo in it.

Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 0 comments |
headers
Jeff Wu via RT | 2 Mar 2009 22:57
Picon
Favicon

Re: [openssl.org #1851] [PATCH] "openssl verify -CAfile mutil_ca.pem site.cert" fails even if mutil_ca.pem contains the chain for site.cert

I checked the CVS changelog, looks good :) Thanks again
http://cvs.openssl.org/chngview?cn=17835

Jeff

On Mon, Mar 2, 2009 at 11:17 AM, Jeff Wu <jeffwu75 <at> gmail.com> wrote:
> Hi, Steve
>
> Thanks for quick response. Since the function (X509_NAME_cmp) is used
> for sort and bsearh, we'd better make sure the return value is
> consistent. say a>b and b>c, then a>c is always expected. My previous
> patch has a clear logic to guarantee this but I am not sure if the fix
> in current snapshot also has the same consistence. It works with the
> test CA files though.
>
> Regards,
>
> Jeff
>
>
> On Fri, Feb 27, 2009 at 3:26 PM, Stephen Henson via RT <rt <at> openssl.org> wrote:
>>
>> Please try this against a recent snapshot of 0.9.8-stable. An update to
>> X509_NAME_cmp which was applied recently should address this.
>>
>> Steve.
>>
>>
>>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Ding via RT | 3 Mar 2009 08:06
Picon
Favicon

[openssl.org #1853] Bugs in ./crpto/x509/x509_vfy.c and ./crpto/x509/x509_cmp.c


Hi all,

In the current release OpenSSL 0.9.8j, there are two bugs in ./crpto/x509/x509_vfy.c and ./crpto/x509/x509_cmp.c

Here are the details:

1) The return value of function X509_NAME_cmp in ./crpto/x509/x509_cmp.c is not consistent.
X509_NAME_cmp(a,b) should not only return boolean value (a=b or not) but also need to return 0 means a>b,
=0 means a=b. Since this function is ued in sort and bsearch function, the return value should be
absolutely consistent. Say if a>b, b>c, then a>c should be expected. The current logic may return
conflict result.

We have a CA cert file which contains over 300 trusted CA certs, if we enumerate the whole list and call
X509_find_by_subjet,   X509_find_by_subjec will failed on some certs due to this problem.

FIX: return a memcmp(a,b) value once we find any diffrence.

2) X509_verify_cert function in ./crpto/x509/x509_vfy.c will only verify cert chain against the first
cert in a trusted CA cert list.

In the same cert file, we have two CA certs that have excat same subjet line. Since  X509_find_by_subjet can
only return the first CA cert found in the list, X509_verify_cert failed to verify a cert signed by the
second CA sert, the root CA cert of this cert is in the ca cert list but cannot be returned  by
X509_find_by_subjet function.

FIX:  X509_find_by_subjet should return a NULL ended x509_NAME array, the X509_verify_cer then can try
all the CA cert instances to verify the cert chain.

BTW, we prepared the CA cert file by importing root CA certs from IE7/Firefox3 and other truscted source. So
(Continue reading)

Permalink | Reply | 0 comments |

Gmane