[openssl-dev] Fwd: [openssl.org #4095] X509_STORE_get_by_subject crash

2015-10-19 Thread tosif tamboli via RT 
Hi,

Can you please help me in below query

Thanks & regards,
Tosif
-- Forwarded message --
From: tosif tamboli 
Date: Fri, Oct 16, 2015 at 3:26 PM
Subject: Re: [openssl.org #4095] X509_STORE_get_by_subject crash
To: r...@openssl.org


My application is written for vxWorks OS and openssl and vxWorks are part
of the binary that I need to verify

On Fri, Oct 16, 2015 at 3:13 PM, tosif tamboli  wrote:

> Hi,
>
> below is my application code
>  sshX509CACertStore = X509_STORE_new();
>
> X509_STORE_set_verify_cb_func(sshX509CACertStore,
>   sshX509CertVerifyCallback);
>  pLookup = X509_STORE_add_lookup(sshX509CACertStore,
> X509_LOOKUP_file());
> X509_LOOKUP_load_file(pLookup,caFile,X509_FILETYPE_PEM)
>
>  X509_STORE_CTX_init (pStoreCtx, sshX509CACertStore, pX509, NULL);
>
>  ret = X509_verify_cert (pStoreCtx);
>
> in the callback function I just checked for
> retVal = X509_STORE_get_by_subject (, X509_LU_CRL,
> pSubject, _obj);
>
>  retVal = X509_STORE_get_by_subject (, X509_LU_CRL,
> pIssuer, _obj);
>
> older openssl used md5 hash and newer doesn't seem to use it
> As you mentioned about c_rehash. How should I create new symlink in code.
> My application is to verify the certificate and signature in image
>
> It will be helpful if you can provide your inputs for crash of above
> application at
> X509_STORE_get_by_subject (, X509_LU_CRL,
> pIssuer, _obj);
>
> Thanks & regards,
> Tosif
>
>
> On Thu, Oct 15, 2015 at 8:16 PM, Emilia Käsper  wrote:
>
>> This sounds like an application problem.
>> 1) Did you recompile your source? 0.9.7 and 1.0.1 are not
>> binary-compatible.
>> 2) The certificate hash format has changed between 1.0.1 and 0.9.7, which
>> could
>> explain why the lookup no longer works:
>> https://www.openssl.org/docs/manmaster/apps/rehash.html
>>
>> If the above isn't helpful, try asking for help on openssl-users@.
>> Rejecting
>> the ticket (though please reopen if you find new evidence that this is a
>> bug
>> within OpenSSL).
>>
>> Cheers,
>> Emilia
>>
>>
>

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

2015-10-19 Thread Albe Laurenz via RT 
Hubert Kario wrote:
>> Fixing this sort of problem is going to be *hard* and probably require
>> quite a lot of non-trivial changes - definitely not the sort of the
>> thing I want to be doing in a stable branch. Fixing this is an
>> example of what I meant by "onerous mitigations", but I now realise
>> it is absolutely necessary if we wanted to pursue this.
>>
>> I think we should be marking this as a "won't fix" for all released
>> versions. The question is whether we should even attempt to fix it for
>> 1.1.0 or not.
> 
> we may actually be able to patch this up partially in 1.0.x
> 
> the original problem description mentions server being unable to process
> application data before Certificate/Client Key Exchange, not in any
> place what so ever
> 
> (Albe, please double check if you didn't saw Java sending app data at
> any different point)

I ran my test with the patched version of OpenSSL 1.0.2, PostgreSQL 9.4.5 and
Java 1.7.0_71 which completes without errors, and this is a Wireshark trace:

  4 0.00274400010.155.6.40   10.153.93.229 TLSv162  
   Ignored Unknown Record
  6 0.00313500010.153.93.229 10.155.6.40   TLSv160  
   Ignored Unknown Record
  7 0.18990200010.155.6.40   10.153.93.229 TLSv1259 
   Client Hello
  8 0.19269900010.153.93.229 10.155.6.40   TLSv1
1485   Server Hello, Certificate, Server Key Exchange, Server Hello Done
  9 0.20114100010.155.6.40   10.153.93.229 TLSv1129 
   Client Key Exchange
 10 0.20897500010.155.6.40   10.153.93.229 TLSv160  
   Change Cipher Spec
 12 0.21034600010.155.6.40   10.153.93.229 TLSv1107 
   Encrypted Handshake Message
 13 0.21073900010.153.93.229 10.155.6.40   TLSv1113 
   Change Cipher Spec, Encrypted Handshake Message
 14 0.21131700010.155.6.40   10.153.93.229 TLSv1187 
   Application Data
 15 0.21224200010.153.93.229 10.155.6.40   TLSv1144 
   Application Data, Application Data
 16 0.21286500010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 17 0.21293200010.155.6.40   10.153.93.229 TLSv1123 
   Application Data
 19 0.2161710.153.93.229 10.155.6.40   TLSv1448 
   Application Data, Application Data
 20 0.22359600010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 21 0.22367100010.155.6.40   10.153.93.229 TLSv1155 
   Application Data
 23 0.22425600010.153.93.229 10.155.6.40   TLSv1144 
   Application Data, Application Data
 24 0.23517500010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 25 0.23525800010.155.6.40   10.153.93.229 TLSv1171 
   Application Data
 27 0.23562200010.153.93.229 10.155.6.40   TLSv1160 
   Application Data, Application Data
 28 0.23610600010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 29 0.23617500010.155.6.40   10.153.93.229 TLSv1155 
   Application Data
 31 0.23703800010.153.93.229 10.155.6.40   TLSv1
1514   Application Data
 37 0.23726500010.153.93.229 10.155.6.40   TLSv1
1020   Application Data
 38 0.23726500010.153.93.229 10.155.6.40   TLSv191  
   Encrypted Handshake Message
 39 0.23726500010.153.93.229 10.155.6.40   TLSv1
1008   Application Data, Application Data
 41 0.24191400010.155.6.40   10.153.93.229 TLSv1331 
   Encrypted Handshake Message
 42 0.24428400010.153.93.229 10.155.6.40   TLSv1
1514   Encrypted Handshake Message, Encrypted Handshake Message
 43 0.24428500010.153.93.229 10.155.6.40   TLSv1150 
   Encrypted Handshake Message
 45 0.24841900010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 46 0.24849200010.155.6.40   10.153.93.229 TLSv1155 
   Application Data
 48 0.25356800010.155.6.40   10.153.93.229 TLSv1155 
   Encrypted Handshake Message
 49 0.25725700010.155.6.40   10.153.93.229 TLSv191  
   Change Cipher Spec
 50 0.25749400010.155.6.40   10.153.93.229 TLSv1107 
   Encrypted Handshake Message
 52 0.25793900010.153.93.229 10.155.6.40   TLSv1144 
   Change Cipher Spec, Encrypted Handshake Message
 53 0.25804800010.153.93.229 10.155.6.40   TLSv1
1514   Application Data
 59 0.25828200010.153.93.229 10.155.6.40   TLSv1
1020   Application Data
 60 0.258283000

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

2015-10-19 Thread Albe Laurenz 
Hubert Kario wrote:
>> Fixing this sort of problem is going to be *hard* and probably require
>> quite a lot of non-trivial changes - definitely not the sort of the
>> thing I want to be doing in a stable branch. Fixing this is an
>> example of what I meant by "onerous mitigations", but I now realise
>> it is absolutely necessary if we wanted to pursue this.
>>
>> I think we should be marking this as a "won't fix" for all released
>> versions. The question is whether we should even attempt to fix it for
>> 1.1.0 or not.
> 
> we may actually be able to patch this up partially in 1.0.x
> 
> the original problem description mentions server being unable to process
> application data before Certificate/Client Key Exchange, not in any
> place what so ever
> 
> (Albe, please double check if you didn't saw Java sending app data at
> any different point)

I ran my test with the patched version of OpenSSL 1.0.2, PostgreSQL 9.4.5 and
Java 1.7.0_71 which completes without errors, and this is a Wireshark trace:

  4 0.00274400010.155.6.40   10.153.93.229 TLSv162  
   Ignored Unknown Record
  6 0.00313500010.153.93.229 10.155.6.40   TLSv160  
   Ignored Unknown Record
  7 0.18990200010.155.6.40   10.153.93.229 TLSv1259 
   Client Hello
  8 0.19269900010.153.93.229 10.155.6.40   TLSv1
1485   Server Hello, Certificate, Server Key Exchange, Server Hello Done
  9 0.20114100010.155.6.40   10.153.93.229 TLSv1129 
   Client Key Exchange
 10 0.20897500010.155.6.40   10.153.93.229 TLSv160  
   Change Cipher Spec
 12 0.21034600010.155.6.40   10.153.93.229 TLSv1107 
   Encrypted Handshake Message
 13 0.21073900010.153.93.229 10.155.6.40   TLSv1113 
   Change Cipher Spec, Encrypted Handshake Message
 14 0.21131700010.155.6.40   10.153.93.229 TLSv1187 
   Application Data
 15 0.21224200010.153.93.229 10.155.6.40   TLSv1144 
   Application Data, Application Data
 16 0.21286500010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 17 0.21293200010.155.6.40   10.153.93.229 TLSv1123 
   Application Data
 19 0.2161710.153.93.229 10.155.6.40   TLSv1448 
   Application Data, Application Data
 20 0.22359600010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 21 0.22367100010.155.6.40   10.153.93.229 TLSv1155 
   Application Data
 23 0.22425600010.153.93.229 10.155.6.40   TLSv1144 
   Application Data, Application Data
 24 0.23517500010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 25 0.23525800010.155.6.40   10.153.93.229 TLSv1171 
   Application Data
 27 0.23562200010.153.93.229 10.155.6.40   TLSv1160 
   Application Data, Application Data
 28 0.23610600010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 29 0.23617500010.155.6.40   10.153.93.229 TLSv1155 
   Application Data
 31 0.23703800010.153.93.229 10.155.6.40   TLSv1
1514   Application Data
 37 0.23726500010.153.93.229 10.155.6.40   TLSv1
1020   Application Data
 38 0.23726500010.153.93.229 10.155.6.40   TLSv191  
   Encrypted Handshake Message
 39 0.23726500010.153.93.229 10.155.6.40   TLSv1
1008   Application Data, Application Data
 41 0.24191400010.155.6.40   10.153.93.229 TLSv1331 
   Encrypted Handshake Message
 42 0.24428400010.153.93.229 10.155.6.40   TLSv1
1514   Encrypted Handshake Message, Encrypted Handshake Message
 43 0.24428500010.153.93.229 10.155.6.40   TLSv1150 
   Encrypted Handshake Message
 45 0.24841900010.155.6.40   10.153.93.229 TLSv191  
   Application Data
 46 0.24849200010.155.6.40   10.153.93.229 TLSv1155 
   Application Data
 48 0.25356800010.155.6.40   10.153.93.229 TLSv1155 
   Encrypted Handshake Message
 49 0.25725700010.155.6.40   10.153.93.229 TLSv191  
   Change Cipher Spec
 50 0.25749400010.155.6.40   10.153.93.229 TLSv1107 
   Encrypted Handshake Message
 52 0.25793900010.153.93.229 10.155.6.40   TLSv1144 
   Change Cipher Spec, Encrypted Handshake Message
 53 0.25804800010.153.93.229 10.155.6.40   TLSv1
1514   Application Data
 59 0.25828200010.153.93.229 10.155.6.40   TLSv1
1020   Application Data
 60 0.258283000

Re: [openssl-dev] OCSP issues in master 2015-10-17

2015-10-19 Thread Dr. Stephen Henson 
On Sat, Oct 17, 2015, Roumen Petrov wrote:

> Hello,
> 
> After embed  some attributes OCSP in master stop to work.
> 
> The current status is the client comment report "Cert Status:
> unknown" and "Nonce Verify error" for X.509 certificates used in my
> ssh regression tests.
> 
> The last known version to work is
> "47c9a1b5096be684c18335137284f0dfcefd12d6 : embed support for
> ASN1_STRING"
> (optionally with "Appease gcc's Wmaybe-uninitialized" if build fail
> due to pedantic compiler flags).
> 
> First regression is from "af170194a88d6127d447bea826845c23ca192727 :
> embed OCSP_CERTID" - status is missing.
> 

Should be fixed by commit 7f3e6f8c243710b8dc89f385196987ad83c7848d in the
master branch.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

2015-10-19 Thread Hubert Kario via RT 
On Monday 19 October 2015 10:19:09 Albe Laurenz via RT wrote:

> 7 0.18990200010.155.6.40   10.153.93.229 TLSv1259
> Client Hello 
> 8 0.19269900010.153.93.229 10.155.6.40   TLSv11485   
> Server Hello, Certificate, Server Key Exchange, Server Hello Done 

so we know that 10.155.6.40 is the client while 10.153.93.229 is the server

> 38 0.23726500010.153.93.229 10.155.6.40   TLSv191 
> Encrypted Handshake Message

Server is sending Hello Request

> 39 0.23726500010.153.93.229 10.155.6.40   TLSv1
> 1008   Application Data, Application Data

Server is continuing sending the data

> 41 0.24191400010.155.6.40   10.153.93.229 TLSv1
> 331Encrypted Handshake Message

Client is sending Client Hello

> 42 0.24428400010.153.93.229 10.155.6.40   TLSv1
> 1514   Encrypted Handshake Message, Encrypted Handshake Message
> 43 0.24428500010.153.93.229 10.155.6.40   TLSv1
> 150Encrypted Handshake Message

Server replies with Server Hello, Certificate and Server Hello Done

> 45 0.24841900010.155.6.40   10.153.93.229 TLSv191 
> Application Data
> 46 0.24849200010.155.6.40   10.153.93.229 TLSv1
> 155Application Data

Client continues sending data

> 48 0.25356800010.155.6.40   10.153.93.229 TLSv1
> 155Encrypted Handshake Message

Client replies to Server Hello Done with Client Key Exchange...

> 49 0.25725700010.155.6.40   10.153.93.229 TLSv191 
> Change Cipher Spec
> 50 0.25749400010.155.6.40   10.153.93.229 TLSv1
> 107Encrypted Handshake Message

...Change Cipher Spec and Finished

> 52 0.25793900010.153.93.229 10.155.6.40   TLSv1
> 144Change Cipher Spec, Encrypted Handshake Message

server replies with Change Cipher Spec and Finished

> 53 0.25804800010.153.93.229 10.155.6.40   TLSv1
> 1514   Application Data
> 59 0.25828200010.153.93.229 10.155.6.40   TLSv1
> 1020   Application Data

server replies with data to client

> Ist that good enough? Can you infer from context which "Encrypted
> Handshake Message" is what?

yes, thank you, if that exchange is typical, then it's enough to allow
application data between Client Hello and Certificate/Client Key Exchange
to at least "patch up" this issue

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c

2015-10-19 Thread Pascal Cuoq via RT 
Hello,

this is a follow-up to #3891 
(https://mta.openssl.org/pipermail/openssl-dev/2015-June/001667.html ). Kurt 
Roeckx has committed many fixes to the bugs aggregated in that report. Since, 
we have been replaying the tests in a recent OpenSSL development version, 
posterior to these commits, to see what issues remained and re-submit them 
individually with more explanation. This means that #3891 can now be closed 
(grouping too many fixes in a same entry may not have been such a good idea 
after all).

First, an old problem for which detection was only implemented recently : the 
memcpy call in bn_add.c can be passed identical pointers, which are thus 
pointing to overlapping zones. The code has been so for a long time and someone 
would likely have noticed if this had practical consequences, but in principle, 
invoking memcpy to copy between overlapping memory zones is undefined behavior 
even if the overlap is exact.

This can be fixed locally as in the attached patch.




bn_memcpy_overlap.patch
Description: Binary data


One actual sequence for which the pointers ap and rp end up being identical is 
as follows:

1/ probable_prime_dh_safe calls BN_sub(q, q, t1)

2/ in BN_sub, r and a are then aliases

3/ BN_sub calls BN_usub(r, a, b) so r and a are still aliases in BN_usub

4/ in BN_usub, ap = a->d; and rp = r->d;
  then the 2 pointers can be incremented, but an identical number of times

5/ then memcpy is called with rp and ap that are still aliases, which is 
undefined behavior___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c

2015-10-19 Thread Kurt Roeckx via RT 
On Mon, Oct 19, 2015 at 08:10:01PM +0200, Kurt Roeckx wrote:
> The manpage says that for BN_add(), BN_mul(), BN_sqr(), BN_mod_mul()
> and BN_gcd() r can be one of the other BIGNUMs that got passed, but
> it doesn't say so for BN_sub().

BN_add() can of course already call BN_usub(), and BN_uadd() also
already has the rp != ap check.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4101] [PATCH] Doc clarification for EVP_DigestVerifyFinal

2015-10-19 Thread Adam Eijdenberg via RT 
Minor doc clarification:
https://github.com/openssl/openssl/pull/446

I embarrassingly misread the previous documentation to indicate that 0 was
a failure and other values mean success and figured others might do the
same.

Cheers, Adam

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c

2015-10-19 Thread Kurt Roeckx via RT 
On Mon, Oct 19, 2015 at 08:10:01PM +0200, Kurt Roeckx wrote:
> The manpage says that for BN_add(), BN_mul(), BN_sqr(), BN_mod_mul()
> and BN_gcd() r can be one of the other BIGNUMs that got passed, but
> it doesn't say so for BN_sub().  So one could also argue that
> probable_prime_dh_safe() shouldn't have called BN_sub() like that.
> But we have various other callers internally that call BN_sub()
> like that.  So we should probably either fix all the callers not
> to do that, or really make sure that it works properly when they
> alias and document that they can.  And I'm currently in favor of
> making it safe for them to alias.  (It should probably only be
> allowed to alias a, not b.)

I think that only allow a to alias and not b doesn't make sense
anymore, and clearly would be a problem since BN_sub() can call
BN_usub() with a and b switched.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c

2015-10-19 Thread Kurt Roeckx via RT 
On Mon, Oct 19, 2015 at 03:55:09PM +, Pascal Cuoq via RT wrote:
> 
> One actual sequence for which the pointers ap and rp end up being identical 
> is as follows:
> 
> 1/ probable_prime_dh_safe calls BN_sub(q, q, t1)
> 
> 2/ in BN_sub, r and a are then aliases
> 
> 3/ BN_sub calls BN_usub(r, a, b) so r and a are still aliases in BN_usub
> 
> 4/ in BN_usub, ap = a->d; and rp = r->d;
>   then the 2 pointers can be incremented, but an identical number of times
> 
> 5/ then memcpy is called with rp and ap that are still aliases, which is 
> undefined behavior

So I've been looking at this, and it seems the patch makes sense
at first sight.

The manpage says that for BN_add(), BN_mul(), BN_sqr(), BN_mod_mul()
and BN_gcd() r can be one of the other BIGNUMs that got passed, but
it doesn't say so for BN_sub().  So one could also argue that
probable_prime_dh_safe() shouldn't have called BN_sub() like that.
But we have various other callers internally that call BN_sub()
like that.  So we should probably either fix all the callers not
to do that, or really make sure that it works properly when they
alias and document that they can.  And I'm currently in favor of
making it safe for them to alias.  (It should probably only be
allowed to alias a, not b.)

But I need to take a closer look to make sure that the patch is
enough or that something else needs to be changed too.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev