seems openssl version 1.0.1g also infected

[LOKESH JANGIR]

Hi Team,

I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I
found the same openssl vulnerability issue with my ssl certificate. I have
installed new openssl bugfixed version 1.0.1g and create csr and key file
from this. Also i have installed this on the server. I have restarted
apache service and server many times after installation.

But still it is showing my website vulnerable. Can you please guide me what
am i missing now ?

Thanks and Regards,
Lokesh Jangir

Re: OpenSSL has exploit mitigation countermeasures to make sure its exploitable

[mancha]

On Sat, Apr 12, 2014 at 09:02:50PM -0400, Salz, Rich wrote:
  Would you please elaborate on how it differs from what you've been
  using in production?
 
 Local platform issues, mainly.  Conceptually, nothing different about
 the security.
 

Hello Rich et al.

I believe Akamai's secure malloc, in current form, to be ineffective
against heartbleed.

In order to achieve ~4-fold improvements in RSA signing speeds, many
implementations (including OpenSSL) bundle pre-computed Chinese
remainder theorem parameters in private keys (so-called quintuple
representation). [1]

Akamai's secure malloc appears to only protect the private exponent (d)
and two primes (p and q) leaving both CRT exponents (e1  e2) and the
first CRT coefficient (coeff) unprotected. 

However, the public exponent (e), modulus (n), and either CRT exponent
(e1 or e2) is sufficient to recover a prime and therefore the full
private key.

Rather than plaster math equations here, I've attached a small perl
script that demonstrates this by way of an example.

Recommendation: protect the rest of the private key material.

My analysis has focused on problems related to *what* should be
protected not on the effectiveness of *how* it is protected. The *how*
also merits close review.  One immediate observation I have on that
front is that secure_malloc_init() is never called.

--mancha

[1] https://tools.ietf.org/html/rfc3447


akamai.pl
Description: Perl program


pgp4KhDIjk_fD.pgp
Description: PGP signature

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

Hello!

What does `ldd /path/to/httpd` says?

Cheers,
Fedor.


On Mon, Apr 14, 2014 at 12:17 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Team,

 I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I
 found the same openssl vulnerability issue with my ssl certificate. I have
 installed new openssl bugfixed version 1.0.1g and create csr and key file
 from this. Also i have installed this on the server. I have restarted
 apache service and server many times after installation.

 But still it is showing my website vulnerable. Can you please guide me
 what am i missing now ?

 Thanks and Regards,
 Lokesh Jangir

Re: heartbeat RFC 6520 and silently drop behaviour

[David Jacobson]

On 4/13/14 3:54 AM, Michael Tuexen wrote:

On 13 Apr 2014, at 01:54, tolga ceylan tolga.cey...@gmail.com wrote:


The RFC has a lot of statements about silently dropping packets in case of
various anomalies. But the correct action should be to drop the connection.
This would uncover faulty implementations and other bugs that may
slide due to 'silently drop' behavior. It'll also make malicious
activity a bit more difficult and exposed due to the necessity to reestablish
connections for any brute force attempts.

What is your opinion on this?

There are two MUST discards. One is the the payload being reflected doesn't 
match,
the other is the the payload_length is too large. The second one is the critical
one for the heartbleed attack. Let us consider this case. It is clear that
you don't respond. You could keep the connection or drop it. When dropping it,
you give the attacker an immediate indication that you are not vulnerable. So
the attacker can move on. If you don't drop the connection, the attacker has to
wait until he decides that the stack is not vulnerable. So it takes more 
resources
on his side. However, the crucial point is to follow the MUST and not send the
heartbeat response...

Best regards
Michael

Cheers,
Tolga Ceylan



First, dropping the connect does not comply with the RFC, which says 
that the heartbeat request MUST be silently discarded.


Second, it is debatable as to whether dropping the connection is a good 
idea.  First is contrary to Postel's Law: an implementation should be 
conservative in its sending behavior, and liberal in its receiving 
behavior.  There may be a coding error in some client and the length is 
1 byte too large.   Now that client can't communicate with the server.  
The client user can't do whatever he wants to do. The server user may be 
losing business.  Neither of these are responsible for the problem nor 
can they do anything about it. Second, yes, it makes the attacker do a 
bit more work. But it is very little, and the attacker can run attacks 
in parallel, so it doesn't make much difference in this throughput.


  --David Jacobson
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[PATCH] heartbeat_test

[Mike Bland]

Unit test for the TLS heartbeat code; acts as a regression test against
CVE-2014-0160.

Thanks,

Mike


heartbeat_test.patch
Description: Binary data

Re: seems openssl version 1.0.1g also infected

[Rainer M. Canavan]

On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com wrote:

 Hi Team,
 
 I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I found 
 the same openssl vulnerability issue with my ssl certificate. I have 
 installed new openssl bugfixed version 1.0.1g and create csr and key file 
 from this. Also i have installed this on the server. I have restarted apache 
 service and server many times after installation. 
 
 But still it is showing my website vulnerable. Can you please guide me what 
 am i missing now ?

did you use apachectl restart, or apachectl stop + apachectl start? If 
you did
the former, the process may still be running with the old, deleted library. Try

sudo lsof -n | grep libssl | grep DEL

to see if that is still the case.


rainer__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[LOKESH JANGIR]

Hi Fedor,

Thanks for the reply. My httpd path is /usr/sbin/httpd and please find the
output of ldd /usr/sbin/httpd

[root@ip-10-253-83-223 openssl-1.0.1g]# ldd /usr/sbin/httpd
linux-vdso.so.1 =  (0x7fffebdfe000)
libm.so.6 = /lib64/libm.so.6 (0x7ff2d74a7000)
libpcre.so.0 = /lib64/libpcre.so.0 (0x7ff2d724e000)
libselinux.so.1 = /usr/lib64/libselinux.so.1 (0x7ff2d702c000)
libaprutil-1.so.0 = /usr/lib64/libaprutil-1.so.0
(0x7ff2d6e08000)
libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7ff2d6bd2000)
libexpat.so.1 = /lib64/libexpat.so.1 (0x7ff2d69a9000)
libdb-4.7.so = /lib64/libdb-4.7.so (0x7ff2d663a000)
libapr-1.so.0 = /usr/lib64/libapr-1.so.0 (0x7ff2d6407000)
libpthread.so.0 = /lib64/libpthread.so.0 (0x7ff2d61ea000)
libc.so.6 = /lib64/libc.so.6 (0x7ff2d5e45000)
libdl.so.2 = /lib64/libdl.so.2 (0x7ff2d5c41000)
/lib64/ld-linux-x86-64.so.2 (0x7ff2d7a09000)
libuuid.so.1 = /lib64/libuuid.so.1 (0x7ff2d5a3c000)
libfreebl3.so = /lib64/libfreebl3.so (0x7ff2d57c6000)


Please have a look and help me.

Regards,
Lokesh Jangir


On Mon, Apr 14, 2014 at 2:13 PM, Fedor Indutny fe...@indutny.com wrote:

 Hello!

 What does `ldd /path/to/httpd` says?

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 12:17 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Team,

 I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I
 found the same openssl vulnerability issue with my ssl certificate. I have
 installed new openssl bugfixed version 1.0.1g and create csr and key file
 from this. Also i have installed this on the server. I have restarted
 apache service and server many times after installation.

 But still it is showing my website vulnerable. Can you please guide me
 what am i missing now ?

 Thanks and Regards,
 Lokesh Jangir

[openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h

[Tom Swirly via RT]

Hello.  This is a small feature request that's applicable to all operating
systems.

*The problem.*

The version numbers for OpenSSL appear in the header opensslv.h as macro
symbols:

OPENSSL_VERSION_NUMBER
OPENSSL_VERSION_TEXT

Unfortunately, it seems that neither of these two variables are actually
used in the OpenSSL library.

This is a pity, because it means that a program that links to the OpenSSL
library has no way to tell if it's *linking* to the correct library - you
can only tell if you are *compiling* with the right header.


*A possible solution.*

A possible solution is to have two global variables declared in opensslv.h,
defined as:

long long openssl_version_number = OPENSSL_VERSION_NUMBER;
const char* openssl_version_text = OPENSSL_VERSION_TEXT;

(It wasn't quite clear to me which file should contain the definitions...)

Then a program linking to this library can read either of these global
variables at runtime and fail to start or emit a warning if the version
isn't up-to-date.


Thanks for your consideration!

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3307] Return missed NULL-check in CMS_add0_cert back

[Andrey Kulikov via RT]

In 1.0.1g duplicated check for (!pcerts) where removed.

Had an impression that second appearance was check for (!*pcerts) (as in
all other functions).

Return it back.
Patch applied.



0001-Check-pcerts-for-NULL.patch
Description: Binary data

[openssl.org #3308] Re: Return missed NULL-check in CMS_add0_cert back

[Andrey Kulikov via RT]

Well...
With this check 'make test' fails with:

CMS = PKCS#7 compatibility tests
signed content DER format, RSA key: generation error
make[1]: *** [test_cms] Error 1




On 14 April 2014 00:16, Andrey Kulikov amde...@gmail.com wrote:

 In 1.0.1g duplicated check for (!pcerts) where removed.

 Had an impression that second appearance was check for (!*pcerts) (as in
 all other functions).

 Return it back.
 Patch applied.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3309] Bug: Missing critical flag for extended key usage not detected in time-stamp verification

[Stephan Mühlstrasser via RT]

Hi,

the following problem was reproduced with several OpenSSL 1.0.1 versions 
and also with a recent build from the OpenSSL_1_0_2-stable branch:

RFC 3161 says in 2.3. Identification of the TSA:

The corresponding certificate MUST contain only one instance of the 
extended key usage field extension as defined in [RFC2459] Section 
4.2.1.13 with KeyPurposeID having value:

id-kp-timeStamping.  This extension MUST be critical.

The openssl ts -verify command resp. the corresponding function 
check_purpose_timestamp_sign() in source file v3_purp.c does check 
this requirement. However, the check fails to detect a missing critical 
flag if the extensions of the TSA certificate are arranged in a specific 
order.

How to reproduce:

Save the three attachments into a directory and run the shell script 
tsacritical.sh. The shell scripts creates a CA and TSA certificate 
from scratch, creates a time-stamp request, a corresponding time-stamp 
reply and verifies the time-stamp reply.

Actual output (only last two lines):

Response has been generated.
Verification: OK

Expected result:

The time-stamp response must not be generated because of the missing 
critical flag for the extended key usage field extension.

The expected result actually is produced if the order of the extension 
in the TSA certificate is reversed. See file tsa.extfile:

With this order the missing critical flag is not detected:

extendedKeyUsage = timeStamping
keyUsage = critical,nonRepudiation

When the order is reversed, the missing critical flag is detected:

keyUsage = critical,nonRepudiation
extendedKeyUsage = timeStamping

With this order of extensions the openssl ts -reply command will fail 
with the following expected error message when running the test script:

Response is not generated.
140735124738912:error:2F083075:time stamp 
routines:TS_RESP_CTX_set_signer_cert:invalid signer certificate 
purpose:ts_rsp_sign.c:206:

The problematic source code is in function 
check_purpose_timestamp_sign() in source file v3_purp.c:

/* Only time stamp key usage is permitted and it's required. */
if (!(x-ex_flags  EXFLAG_XKUSAGE) || x-ex_xkusage != XKU_TIMESTAMP)
 return 0;

/* Extended Key Usage MUST be critical */
i_ext = X509_get_ext_by_NID((X509 *) x, NID_ext_key_usage, 0);
if (i_ext = 0)
 {
 X509_EXTENSION *ext = X509_get_ext((X509 *) x, i_ext);
 if (!X509_EXTENSION_get_critical(ext))
 return 0;
 }

return 1;

With the bad extension order (1) extendedKeyUsage, (2) keyUsage the 
function X509_get_ext_by_NID() does not retrieve the extension and 
returns a negative return value. Therefore the condition (i_ext = 0) is 
false and 1 is returned.

I was not able to find the root cause why X509_get_ext_by_NID() fails to 
retrieve the extension here, but the function 
check_purpose_timestamp_sign() should also not return 1 if the extended 
key usage extension cannot be retrieved, as the first if statement has 
already checked via the flags that the extended key usage exists and the 
the value is timeStamping.

Best Regards
Stephan Muehlstrasser

[ tsa_config1 ]

serial = tsaserial
digests = md5, sha1, sha256, sha384, sha512
default_policy = 1.2.3.4
crypto_device = builtin
[ tsa_cert ]

# This extension order triggers the bug that OpenSSL cannot detect
# the absence of the critical flag of the extendedKeyUsage extension
extendedKeyUsage = timeStamping
keyUsage = critical,nonRepudiation

# With this order the timestamp certificate is correctly rejected by
# openssl ts -reply
# keyUsage = critical,nonRepudiation
# extendedKeyUsage = timeStamping


tsacritical.sh
Description: Bourne shell script

Re: seems openssl version 1.0.1g also infected

[LOKESH JANGIR]

Hi Rainer,

Yes, apache was running with the old library, i have moved this out, and
copied new libssl library from new openssl installation folder. But it is
not working and now i am unable to start apache.

Now what to do with this ?

Regards,
Lokesh Jangir


On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I
 found the same openssl vulnerability issue with my ssl certificate. I have
 installed new openssl bugfixed version 1.0.1g and create csr and key file
 from this. Also i have installed this on the server. I have restarted
 apache service and server many times after installation.
 
  But still it is showing my website vulnerable. Can you please guide me
 what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl start?
 If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

So, considering that it fails to start now. Could you please verify that
`ls -la /lib64/libcrypt.so.1` is still valid?

Fedor.


On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Rainer,

 Yes, apache was running with the old library, i have moved this out, and
 copied new libssl library from new openssl installation folder. But it is
 not working and now i am unable to start apache.

 Now what to do with this ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
 rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I
 found the same openssl vulnerability issue with my ssl certificate. I have
 installed new openssl bugfixed version 1.0.1g and create csr and key file
 from this. Also i have installed this on the server. I have restarted
 apache service and server many times after installation.
 
  But still it is showing my website vulnerable. Can you please guide me
 what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl start?
 If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[LOKESH JANGIR]

Hi Fedor,

Yes i did not move this file out. and i can see the output of ls -la
/lib64/libcrypt.so.1

libcrypt.so - ../../lib64/libcrypt.so.1


I complied openssl and it created this library files,
engines  libcrypto.a  libssl.a  pkgconfig

So now should i move this libcrypt.a file to /usr/lib64 folder and rename
this as .so ?

Regards,
Lokesh Jangir


On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny fe...@indutny.com wrote:

 So, considering that it fails to start now. Could you please verify that
 `ls -la /lib64/libcrypt.so.1` is still valid?

 Fedor.


 On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Rainer,

 Yes, apache was running with the old library, i have moved this out, and
 copied new libssl library from new openssl installation folder. But it is
 not working and now i am unable to start apache.

 Now what to do with this ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
 rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I
 found the same openssl vulnerability issue with my ssl certificate. I have
 installed new openssl bugfixed version 1.0.1g and create csr and key file
 from this. Also i have installed this on the server. I have restarted
 apache service and server many times after installation.
 
  But still it is showing my website vulnerable. Can you please guide me
 what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl
 start? If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

Hello again!

That depends on your setup. I'd suppose that OpenSSL's default installer
should
create symlinks itself. If it did and they doesn't match the previous
location - you
could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
/lib64/libcrypt.so.1`

Cheers,
Fedor.


On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Fedor,

 Yes i did not move this file out. and i can see the output of ls -la 
 /lib64/libcrypt.so.1

 libcrypt.so - ../../lib64/libcrypt.so.1


 I complied openssl and it created this library files,
 engines  libcrypto.a  libssl.a  pkgconfig

 So now should i move this libcrypt.a file to /usr/lib64 folder and rename
 this as .so ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny fe...@indutny.com wrote:

 So, considering that it fails to start now. Could you please verify that
 `ls -la /lib64/libcrypt.so.1` is still valid?

 Fedor.


 On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Rainer,

 Yes, apache was running with the old library, i have moved this out, and
 copied new libssl library from new openssl installation folder. But it is
 not working and now i am unable to start apache.

 Now what to do with this ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
 rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com
 wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed.
 I found the same openssl vulnerability issue with my ssl certificate. I
 have installed new openssl bugfixed version 1.0.1g and create csr and key
 file from this. Also i have installed this on the server. I have restarted
 apache service and server many times after installation.
 
  But still it is showing my website vulnerable. Can you please guide
 me what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl
 start? If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: heartbeat RFC 6520 and silently drop behaviour

[Michael Tuexen]

On 13 Apr 2014, at 17:48, David Jacobson dmjacob...@sbcglobal.net wrote:

 On 4/13/14 3:54 AM, Michael Tuexen wrote:
 On 13 Apr 2014, at 01:54, tolga ceylan tolga.cey...@gmail.com wrote:
 
 The RFC has a lot of statements about silently dropping packets in case of
 various anomalies. But the correct action should be to drop the connection.
 This would uncover faulty implementations and other bugs that may
 slide due to 'silently drop' behavior. It'll also make malicious
 activity a bit more difficult and exposed due to the necessity to 
 reestablish
 connections for any brute force attempts.
 
 What is your opinion on this?
 There are two MUST discards. One is the the payload being reflected doesn't 
 match,
 the other is the the payload_length is too large. The second one is the 
 critical
 one for the heartbleed attack. Let us consider this case. It is clear that
 you don't respond. You could keep the connection or drop it. When dropping 
 it,
 you give the attacker an immediate indication that you are not vulnerable. So
 the attacker can move on. If you don't drop the connection, the attacker has 
 to
 wait until he decides that the stack is not vulnerable. So it takes more 
 resources
 on his side. However, the crucial point is to follow the MUST and not send 
 the
 heartbeat response...
 
 Best regards
 Michael
 Cheers,
 Tolga Ceylan
 
 
 First, dropping the connect does not comply with the RFC, which says that the 
 heartbeat request MUST be silently discarded.
I know (I'm a co-author)...
 
 Second, it is debatable as to whether dropping the connection is a good idea. 
  First is contrary to Postel's Law: an implementation should be conservative 
 in its sending behavior, and liberal in its 
That is what I wanted to say... The crucial point is not to respond with an 
Heartbeat response.
There are arguments for dropping the connections, the are arguments against it.
The consensus was for silently discard. I just wanted to make the options clear.
 receiving behavior.  There may be a coding error in some client and the 
 length is 1 byte too large.   Now that client can't communicate with the 
 server.  The client user can't do whatever he wants to do. The server user 
 may be losing business.  Neither of these are responsible for the problem nor 
 can they do anything about it. Second, yes, it makes the attacker do a bit 
 more work. But it is very little, and the attacker can run attacks in 
 parallel, so it doesn't make much difference in this throughput.
The difference is not big,  agree.

Best regards
Michael
 
  --David Jacobson
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org
 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[LOKESH JANGIR]

Hi,

I am installing openssl in /usr/local/openssl folder and it is creating
libssl.a and libcrypt.a library files. so how can i use these files as
library. Or i need to install this in default folders.
Should i follow this article
http://www.akadia.com/services/ssh_test_certificate.html

Lokesh Jangir


On Mon, Apr 14, 2014 at 4:50 PM, Fedor Indutny fe...@indutny.com wrote:

 Hello again!

 That depends on your setup. I'd suppose that OpenSSL's default installer
 should
 create symlinks itself. If it did and they doesn't match the previous
 location - you
 could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
 /lib64/libcrypt.so.1`

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Fedor,

 Yes i did not move this file out. and i can see the output of ls -la 
 /lib64/libcrypt.so.1

 libcrypt.so - ../../lib64/libcrypt.so.1


 I complied openssl and it created this library files,
 engines  libcrypto.a  libssl.a  pkgconfig

 So now should i move this libcrypt.a file to /usr/lib64 folder and rename
 this as .so ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny fe...@indutny.com wrote:

 So, considering that it fails to start now. Could you please verify that
 `ls -la /lib64/libcrypt.so.1` is still valid?

 Fedor.


 On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Rainer,

 Yes, apache was running with the old library, i have moved this out,
 and copied new libssl library from new openssl installation folder. But it
 is not working and now i am unable to start apache.

 Now what to do with this ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
 rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com
 wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed.
 I found the same openssl vulnerability issue with my ssl certificate. I
 have installed new openssl bugfixed version 1.0.1g and create csr and key
 file from this. Also i have installed this on the server. I have restarted
 apache service and server many times after installation.
 
  But still it is showing my website vulnerable. Can you please guide
 me what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl
 start? If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[Jason Gerfen]

If I had ever needed to use different versions of OpenSSL I would use the
./config --openssldir=/path/to/openssl-ver then for Apache to use that
during installation. Example:
./configure --with-ssl=/path/to/openssl-ver --enable-ssl

That will at least verify your using the new patched version.



On Mon, Apr 14, 2014 at 5:20 AM, Fedor Indutny fe...@indutny.com wrote:

 Hello again!

 That depends on your setup. I'd suppose that OpenSSL's default installer
 should
 create symlinks itself. If it did and they doesn't match the previous
 location - you
 could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
 /lib64/libcrypt.so.1`

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Fedor,

 Yes i did not move this file out. and i can see the output of ls -la 
 /lib64/libcrypt.so.1

 libcrypt.so - ../../lib64/libcrypt.so.1


 I complied openssl and it created this library files,
 engines  libcrypto.a  libssl.a  pkgconfig

 So now should i move this libcrypt.a file to /usr/lib64 folder and rename
 this as .so ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny fe...@indutny.com wrote:

 So, considering that it fails to start now. Could you please verify that
 `ls -la /lib64/libcrypt.so.1` is still valid?

 Fedor.


 On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Rainer,

 Yes, apache was running with the old library, i have moved this out,
 and copied new libssl library from new openssl installation folder. But it
 is not working and now i am unable to start apache.

 Now what to do with this ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
 rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com
 wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed.
 I found the same openssl vulnerability issue with my ssl certificate. I
 have installed new openssl bugfixed version 1.0.1g and create csr and key
 file from this. Also i have installed this on the server. I have restarted
 apache service and server many times after installation.
 
  But still it is showing my website vulnerable. Can you please guide
 me what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl
 start? If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org








-- 
Jason Gerfen
http://github.com/jas- http://www.github.com/jas-

http://phpdhcpadmin.sourceforge.net

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

I guess you need to build it in a shared library mode. Take a look at this:

http://www.linuxfromscratch.org/blfs/view/svn/postlfs/openssl.html .

You may skip applying some unverified patches as author suggest, but
generally
the instructions are correct.

Cheers,
Fedor.


On Mon, Apr 14, 2014 at 3:29 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi,

 I am installing openssl in /usr/local/openssl folder and it is creating
 libssl.a and libcrypt.a library files. so how can i use these files as
 library. Or i need to install this in default folders.
 Should i follow this article
 http://www.akadia.com/services/ssh_test_certificate.html

 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:50 PM, Fedor Indutny fe...@indutny.com wrote:

 Hello again!

 That depends on your setup. I'd suppose that OpenSSL's default installer
 should
 create symlinks itself. If it did and they doesn't match the previous
 location - you
 could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
 /lib64/libcrypt.so.1`

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Fedor,

 Yes i did not move this file out. and i can see the output of ls -la 
 /lib64/libcrypt.so.1

 libcrypt.so - ../../lib64/libcrypt.so.1


 I complied openssl and it created this library files,
 engines  libcrypto.a  libssl.a  pkgconfig

 So now should i move this libcrypt.a file to /usr/lib64 folder and
 rename this as .so ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny fe...@indutny.comwrote:

 So, considering that it fails to start now. Could you please verify
 that `ls -la /lib64/libcrypt.so.1` is still valid?

 Fedor.


 On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR 
 lk.jangi...@gmail.comwrote:

 Hi Rainer,

 Yes, apache was running with the old library, i have moved this out,
 and copied new libssl library from new openssl installation folder. But it
 is not working and now i am unable to start apache.

 Now what to do with this ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
 rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com
 wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl
 installed. I found the same openssl vulnerability issue with my ssl
 certificate. I have installed new openssl bugfixed version 1.0.1g and
 create csr and key file from this. Also i have installed this on the
 server. I have restarted apache service and server many times after
 installation.
 
  But still it is showing my website vulnerable. Can you please guide
 me what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl
 start? If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project
 http://www.openssl.org
 Development Mailing List
 openssl-dev@openssl.org
 Automated List Manager
 majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[Olivier BARTHELEMY]

I use
export CFLAGS=-fPIC
./config shared --prefix=$inst  \
make
to build the shared library version i use


2014-04-14 13:34 GMT+02:00 Fedor Indutny fe...@indutny.com:

 I guess you need to build it in a shared library mode. Take a look at this:

 http://www.linuxfromscratch.org/blfs/view/svn/postlfs/openssl.html .

 You may skip applying some unverified patches as author suggest, but
 generally
 the instructions are correct.

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 3:29 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi,

 I am installing openssl in /usr/local/openssl folder and it is creating
 libssl.a and libcrypt.a library files. so how can i use these files as
 library. Or i need to install this in default folders.
 Should i follow this article
 http://www.akadia.com/services/ssh_test_certificate.html

 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:50 PM, Fedor Indutny fe...@indutny.com wrote:

 Hello again!

 That depends on your setup. I'd suppose that OpenSSL's default installer
 should
 create symlinks itself. If it did and they doesn't match the previous
 location - you
 could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
 /lib64/libcrypt.so.1`

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi Fedor,

 Yes i did not move this file out. and i can see the output of ls -la 
 /lib64/libcrypt.so.1

 libcrypt.so - ../../lib64/libcrypt.so.1


 I complied openssl and it created this library files,
 engines  libcrypto.a  libssl.a  pkgconfig

 So now should i move this libcrypt.a file to /usr/lib64 folder and
 rename this as .so ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny fe...@indutny.comwrote:

 So, considering that it fails to start now. Could you please verify
 that `ls -la /lib64/libcrypt.so.1` is still valid?

 Fedor.


 On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR 
 lk.jangi...@gmail.comwrote:

 Hi Rainer,

 Yes, apache was running with the old library, i have moved this out,
 and copied new libssl library from new openssl installation folder. But 
 it
 is not working and now i am unable to start apache.

 Now what to do with this ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
 rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com
 wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl
 installed. I found the same openssl vulnerability issue with my ssl
 certificate. I have installed new openssl bugfixed version 1.0.1g and
 create csr and key file from this. Also i have installed this on the
 server. I have restarted apache service and server many times after
 installation.
 
  But still it is showing my website vulnerable. Can you please
 guide me what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl
 start? If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project
 http://www.openssl.org
 Development Mailing List
 openssl-dev@openssl.org
 Automated List Manager
 majord...@openssl.org










-- 
[image: Geovariances]

Olivier BARTHELEMY *Software development engineer*
Geovariances, 49bis avenue Franklin Roosevelt - 77215 AVON CEDEX - FRANCE
| www.geovariances.com http://link.geovariances.com/eml-home
Keep posted about Geovariances   http://link.geovariances.com/eml-geowidget
http://link.geovariances.com/eml-linkedin-gv
http://link.geovariances.com/eml-linkedin
http://link.geovariances.com/eml-twitter
http://link.geovariances.com/eml-youtube
http://link.geovariances.com/eml-slideshare

Re: seems openssl version 1.0.1g also infected

[Fedor Indutny]

Yes, I agree with everyone. Just thought that linking a blog post would be
more helpful.

Better use instructions provided here, than at that page.

Thank you, guys!


On Mon, Apr 14, 2014 at 3:40 PM, Olivier BARTHELEMY 
barthel...@geovariances.com wrote:

 I use
 export CFLAGS=-fPIC
 ./config shared --prefix=$inst  \
 make
 to build the shared library version i use


 2014-04-14 13:34 GMT+02:00 Fedor Indutny fe...@indutny.com:

 I guess you need to build it in a shared library mode. Take a look at this:

 http://www.linuxfromscratch.org/blfs/view/svn/postlfs/openssl.html .

 You may skip applying some unverified patches as author suggest, but
 generally
 the instructions are correct.

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 3:29 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi,

 I am installing openssl in /usr/local/openssl folder and it is creating
 libssl.a and libcrypt.a library files. so how can i use these files as
 library. Or i need to install this in default folders.
 Should i follow this article
 http://www.akadia.com/services/ssh_test_certificate.html

 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:50 PM, Fedor Indutny fe...@indutny.comwrote:

 Hello again!

 That depends on your setup. I'd suppose that OpenSSL's default
 installer should
 create symlinks itself. If it did and they doesn't match the previous
 location - you
 could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
 /lib64/libcrypt.so.1`

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR 
 lk.jangi...@gmail.comwrote:

 Hi Fedor,

 Yes i did not move this file out. and i can see the output of ls -la 
 /lib64/libcrypt.so.1

 libcrypt.so - ../../lib64/libcrypt.so.1


 I complied openssl and it created this library files,
 engines  libcrypto.a  libssl.a  pkgconfig

 So now should i move this libcrypt.a file to /usr/lib64 folder and
 rename this as .so ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny fe...@indutny.comwrote:

 So, considering that it fails to start now. Could you please verify
 that `ls -la /lib64/libcrypt.so.1` is still valid?

 Fedor.


 On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR lk.jangi...@gmail.com
  wrote:

 Hi Rainer,

 Yes, apache was running with the old library, i have moved this out,
 and copied new libssl library from new openssl installation folder. But 
 it
 is not working and now i am unable to start apache.

 Now what to do with this ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
 rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com
 wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl
 installed. I found the same openssl vulnerability issue with my ssl
 certificate. I have installed new openssl bugfixed version 1.0.1g and
 create csr and key file from this. Also i have installed this on the
 server. I have restarted apache service and server many times after
 installation.
 
  But still it is showing my website vulnerable. Can you please
 guide me what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl
 start? If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project
 http://www.openssl.org
 Development Mailing List
 openssl-dev@openssl.org
 Automated List Manager
 majord...@openssl.org










 --
 [image: Geovariances]

 Olivier BARTHELEMY *Software development engineer*
 Geovariances, 49bis avenue Franklin Roosevelt - 77215 AVON CEDEX - FRANCE
 | www.geovariances.com http://link.geovariances.com/eml-home
 Keep posted about Geovariances   http://link.geovariances.com/eml-geowidget
 http://link.geovariances.com/eml-linkedin-gv   
 http://link.geovariances.com/eml-linkedin
 http://link.geovariances.com/eml-twitter   
 http://link.geovariances.com/eml-youtube
 http://link.geovariances.com/eml-slideshare

Re: seems openssl version 1.0.1g also infected

[Martin Simmons]

Why are building your own openssl?  Did you try the official Ubuntu update?

sudo apt-get update
sudo apt-get upgrade

__Martin


 On Mon, 14 Apr 2014 16:59:06 +0530, LOKESH JANGIR said:
 
 Hi,
 
 I am installing openssl in /usr/local/openssl folder and it is creating
 libssl.a and libcrypt.a library files. so how can i use these files as
 library. Or i need to install this in default folders.
 Should i follow this article
 http://www.akadia.com/services/ssh_test_certificate.html
 
 Lokesh Jangir
 
 
 On Mon, Apr 14, 2014 at 4:50 PM, Fedor Indutny fe...@indutny.com wrote:
 
  Hello again!
 
  That depends on your setup. I'd suppose that OpenSSL's default installer
  should
  create symlinks itself. If it did and they doesn't match the previous
  location - you
  could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
  /lib64/libcrypt.so.1`
 
  Cheers,
  Fedor.
 
 
  On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:
 
  Hi Fedor,
 
  Yes i did not move this file out. and i can see the output of ls -la 
  /lib64/libcrypt.so.1
 
  libcrypt.so - ../../lib64/libcrypt.so.1
 
 
  I complied openssl and it created this library files,
  engines  libcrypto.a  libssl.a  pkgconfig
 
  So now should i move this libcrypt.a file to /usr/lib64 folder and rename
  this as .so ?
 
  Regards,
  Lokesh Jangir
 
 
  On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny fe...@indutny.com wrote:
 
  So, considering that it fails to start now. Could you please verify that
  `ls -la /lib64/libcrypt.so.1` is still valid?
 
  Fedor.
 
 
  On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR 
  lk.jangi...@gmail.comwrote:
 
  Hi Rainer,
 
  Yes, apache was running with the old library, i have moved this out,
  and copied new libssl library from new openssl installation folder. But 
  it
  is not working and now i am unable to start apache.
 
  Now what to do with this ?
 
  Regards,
  Lokesh Jangir
 
 
  On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
  rainer.cana...@sevenval.com wrote:
 
 
 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com
 wrote:
 
  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed.
 I found the same openssl vulnerability issue with my ssl certificate. I
 have installed new openssl bugfixed version 1.0.1g and create csr and key
 file from this. Also i have installed this on the server. I have restarted
 apache service and server many times after installation.
 
  But still it is showing my website vulnerable. Can you please guide
 me what am i missing now ?
 
 did you use apachectl restart, or apachectl stop + apachectl
 start? If you did
 the former, the process may still be running with the old, deleted
 library. Try
 
 sudo lsof -n | grep libssl | grep DEL
 
 to see if that is still the case.
 
 
 
 rainer__
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org
 
 
 
 
 
 
 
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[Jason Gerfen]

The wiki provides some very useful information
http://wiki.openssl.org/index.php/Compilation_and_Installation


On Mon, Apr 14, 2014 at 5:40 AM, Olivier BARTHELEMY 
barthel...@geovariances.com wrote:

 I use
 export CFLAGS=-fPIC
 ./config shared --prefix=$inst  \
 make
 to build the shared library version i use


 2014-04-14 13:34 GMT+02:00 Fedor Indutny fe...@indutny.com:

 I guess you need to build it in a shared library mode. Take a look at this:

 http://www.linuxfromscratch.org/blfs/view/svn/postlfs/openssl.html .

 You may skip applying some unverified patches as author suggest, but
 generally
 the instructions are correct.

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 3:29 PM, LOKESH JANGIR lk.jangi...@gmail.comwrote:

 Hi,

 I am installing openssl in /usr/local/openssl folder and it is creating
 libssl.a and libcrypt.a library files. so how can i use these files as
 library. Or i need to install this in default folders.
 Should i follow this article
 http://www.akadia.com/services/ssh_test_certificate.html

 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:50 PM, Fedor Indutny fe...@indutny.comwrote:

 Hello again!

 That depends on your setup. I'd suppose that OpenSSL's default
 installer should
 create symlinks itself. If it did and they doesn't match the previous
 location - you
 could try creating a new one: `ln -s /path/to/new/libcrypto.so.1
 /lib64/libcrypt.so.1`

 Cheers,
 Fedor.


 On Mon, Apr 14, 2014 at 3:13 PM, LOKESH JANGIR 
 lk.jangi...@gmail.comwrote:

 Hi Fedor,

 Yes i did not move this file out. and i can see the output of ls -la 
 /lib64/libcrypt.so.1

 libcrypt.so - ../../lib64/libcrypt.so.1


 I complied openssl and it created this library files,
 engines  libcrypto.a  libssl.a  pkgconfig

 So now should i move this libcrypt.a file to /usr/lib64 folder and
 rename this as .so ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 4:31 PM, Fedor Indutny fe...@indutny.comwrote:

 So, considering that it fails to start now. Could you please verify
 that `ls -la /lib64/libcrypt.so.1` is still valid?

 Fedor.


 On Mon, Apr 14, 2014 at 2:53 PM, LOKESH JANGIR lk.jangi...@gmail.com
  wrote:

 Hi Rainer,

 Yes, apache was running with the old library, i have moved this out,
 and copied new libssl library from new openssl installation folder. But 
 it
 is not working and now i am unable to start apache.

 Now what to do with this ?

 Regards,
 Lokesh Jangir


 On Mon, Apr 14, 2014 at 2:52 PM, Rainer M. Canavan 
 rainer.cana...@sevenval.com wrote:


 On Apr 14, 2014, at 10:17 , LOKESH JANGIR lk.jangi...@gmail.com
 wrote:

  Hi Team,
 
  I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl
 installed. I found the same openssl vulnerability issue with my ssl
 certificate. I have installed new openssl bugfixed version 1.0.1g and
 create csr and key file from this. Also i have installed this on the
 server. I have restarted apache service and server many times after
 installation.
 
  But still it is showing my website vulnerable. Can you please
 guide me what am i missing now ?

 did you use apachectl restart, or apachectl stop + apachectl
 start? If you did
 the former, the process may still be running with the old, deleted
 library. Try

 sudo lsof -n | grep libssl | grep DEL

 to see if that is still the case.



 rainer__
 OpenSSL Project
 http://www.openssl.org
 Development Mailing List
 openssl-dev@openssl.org
 Automated List Manager
 majord...@openssl.org










 --
 [image: Geovariances]

 Olivier BARTHELEMY *Software development engineer*
 Geovariances, 49bis avenue Franklin Roosevelt - 77215 AVON CEDEX - FRANCE
 | www.geovariances.com http://link.geovariances.com/eml-home
 Keep posted about Geovariances   http://link.geovariances.com/eml-geowidget
 http://link.geovariances.com/eml-linkedin-gv   
 http://link.geovariances.com/eml-linkedin
 http://link.geovariances.com/eml-twitter   
 http://link.geovariances.com/eml-youtube
 http://link.geovariances.com/eml-slideshare




-- 
Jason Gerfen
http://github.com/jas- http://www.github.com/jas-

http://phpdhcpadmin.sourceforge.net

RE: RSA [FIPS 186-4] issue

[Leon Brits]

JDM,

 Leon Brits wrote
  I am in no way capable of writing such a patch and was hoping that
  someone is willing to share.
  To be more specific I need a patch that will change the key generation
  from:
  d = e-1 mod((p-1)(q-1))
  to this:
  d = e-1 mod(LCM(p-1, q-1))
 
 We’re also pursuing a patch to RSA Key Generation.  Leon, are you saying
 that you believe this is the change that is necessary in order for it to
 be validated?  What makes you think that?  I think you’re further along in
 the process than we are and I’d like to learn from what you’ve found.

The information I've given comes from a discussion our validation company had 
with someone at NIST. It seems to be the crux of the matter for NIST to go from 
186-2 to 4. I am not sure what else may need to be changed.

RE: seems openssl version 1.0.1g also infected

[Salz, Rich]

 Why are building your own openssl?  Did you try the official Ubuntu update?

Especially since the original poster seems to have problems with the basic 
software engineering stuff.  (No criticism intended, it can be confusing.)

/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[TJ]

On 14/04/14 10:42, LOKESH JANGIR wrote:

I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I


The oldest still-supported Ubuntu version - 10.04 Lucid Lynx - ships with:

apache2.2-bin (2.2.14-5ubuntu8.13) [security]


Hi Fedor,

Thanks for the reply. My httpd path is /usr/sbin/httpd and please find the
output of ldd /usr/sbin/httpd


Ubuntu does not distribute the apache packages with this file; it is renamed to:

/usr/sbin/apache2



[root@ip-10-253-83-223 openssl-1.0.1g]# ldd /usr/sbin/httpd
 linux-vdso.so.1 =  (0x7fffebdfe000)
 libm.so.6 = /lib64/libm.so.6 (0x7ff2d74a7000)
 libpcre.so.0 = /lib64/libpcre.so.0 (0x7ff2d724e000)
 libselinux.so.1 = /usr/lib64/libselinux.so.1 (0x7ff2d702c000)


Ubuntu 64-bit packages don't install here, but to:

$ apt-file search '/libselinux.so.1'
libselinux1: /lib/x86_64-linux-gnu/libselinux.so.1

Also, apache2 does not build against (depend) on selinux:

$ dpkg-query -S /usr/sbin/apache2
apache2-bin: /usr/sbin/apache2

$ ldd /usr/sbin/apache2 | grep selinux
$ apt-cache depends apache2-bin | grep selinux
$

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[LOKESH JANGIR]

Hi team,

I am using amazon ami release  Amazon Linux AMI release 2014.03. When i
restart httpd service then i can see in logs that old version of openssl is
loading with this. Can you please guide me what to do in this case ?

Regards,
Lokesh



On Mon, Apr 14, 2014 at 10:36 PM, TJ 0.open...@iam.tj wrote:

 On 14/04/14 10:42, LOKESH JANGIR wrote:

 I am using Ubuntu, Amazon ami with apache 2.0 and mod_ssl installed. I


 The oldest still-supported Ubuntu version - 10.04 Lucid Lynx - ships with:

 apache2.2-bin (2.2.14-5ubuntu8.13) [security]


  Hi Fedor,

 Thanks for the reply. My httpd path is /usr/sbin/httpd and please find the
 output of ldd /usr/sbin/httpd


 Ubuntu does not distribute the apache packages with this file; it is
 renamed to:

 /usr/sbin/apache2



 [root@ip-10-253-83-223 openssl-1.0.1g]# ldd /usr/sbin/httpd
  linux-vdso.so.1 =  (0x7fffebdfe000)
  libm.so.6 = /lib64/libm.so.6 (0x7ff2d74a7000)
  libpcre.so.0 = /lib64/libpcre.so.0 (0x7ff2d724e000)
  libselinux.so.1 = /usr/lib64/libselinux.so.1
 (0x7ff2d702c000)


 Ubuntu 64-bit packages don't install here, but to:

 $ apt-file search '/libselinux.so.1'
 libselinux1: /lib/x86_64-linux-gnu/libselinux.so.1

 Also, apache2 does not build against (depend) on selinux:

 $ dpkg-query -S /usr/sbin/apache2
 apache2-bin: /usr/sbin/apache2

 $ ldd /usr/sbin/apache2 | grep selinux
 $ apt-cache depends apache2-bin | grep selinux

 $

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

Re: seems openssl version 1.0.1g also infected

[mancha]

On Mon, Apr 14, 2014 at 10:57:37PM +0530, LOKESH JANGIR wrote:
 Hi team,
 
 I am using amazon ami release  Amazon Linux AMI release 2014.03. When i
 restart httpd service then i can see in logs that old version of openssl is
 loading with this. Can you please guide me what to do in this case ?
 
 Regards,
 Lokesh

Hello.

You are more likely to receive help through Amazon support or 
openssl-users. The development list is concerned primarily with
development.

Thank you.

--mancha


pgpNjHFuwB9X9.pgp
Description: PGP signature

Re: [openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h

[Kurt Roeckx via RT]

On Mon, Apr 14, 2014 at 11:51:53AM +0200, Tom Swirly via RT wrote:
 Hello.  This is a small feature request that's applicable to all operating
 systems.
 
 *The problem.*
 
 The version numbers for OpenSSL appear in the header opensslv.h as macro
 symbols:
 
 OPENSSL_VERSION_NUMBER
 OPENSSL_VERSION_TEXT
 
 Unfortunately, it seems that neither of these two variables are actually
 used in the OpenSSL library.
 
 This is a pity, because it means that a program that links to the OpenSSL
 library has no way to tell if it's *linking* to the correct library - you
 can only tell if you are *compiling* with the right header.
 
 
 *A possible solution.*
 
 A possible solution is to have two global variables declared in opensslv.h,
 defined as:
 
 long long openssl_version_number = OPENSSL_VERSION_NUMBER;
 const char* openssl_version_text = OPENSSL_VERSION_TEXT;

That last thing will not work properly because it would create a
relocation for that with a fixed size to copy it from the shared
library to the program, because you can't have text relocations.
So the program that links to it might not see the whole string, or
might copy a too long string.  You really want to use a function.

There are also already those function:
const char *SSLeay_version(int type);
unsigned long SSLeay(void);

 Then a program linking to this library can read either of these global
 variables at runtime and fail to start or emit a warning if the version
 isn't up-to-date.

Please don't do that.  You only create problems if you check the
version.  I've actually had to remove checks like that from
existing programs because it only causes problems.


Kurt


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h

[Tom Swirly via RT]

Thanks for a fast and clear reply!

On Mon, Apr 14, 2014 at 1:58 PM, Kurt Roeckx via RT r...@openssl.org wrote:

  Then a program linking to this library can read either of these global
  variables at runtime and fail to start or emit a warning if the version
  isn't up-to-date.

 Please don't do that.  You only create problems if you check the
 version.  I've actually had to remove checks like that from
 existing programs because it only causes problems.


We'd like to make sure that the libraries we're linking to are up-to-date.
 There are third parties who build our codebase who might not be as careful
as we might like.

Is there some other way to accomplish this?

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h

[Viktor Dukhovni]

On Mon, Apr 14, 2014 at 08:27:17PM +0200, Tom Swirly via RT wrote:

 We'd like to make sure that the libraries we're linking to are
 up-to-date.  There are third parties who build our codebase who
 might not be as careful
 as we might like.

Postfix issues warnings whent the run-time library version looks
sufficiently different from the compile-time library.  However, it
is not possible to use the run-time reported patch level to detect
whether a particular fix is applied.  Many vendor releases of
OpenSSL backport fixes without updating the library patch level.

In part this is because OpenSSL patch levels are still not just
patches.  For example, a new feature (padding extension) was added
between 1.0.1f and 1.0.1g.  This is unfortunate, as new features
were not supposed to be added in patch releases starting with 1.0.0.

It would be good to actually move to a strict buf-fix only policy
for patch releases as of some future OpenSSL release.

 /*
  * Parsed OpenSSL version number.
  */
typedef struct {
int major;
int minor;
int micro;
int patch;
int status;
} TLS_VINFO;

/* tls_version_split - Split OpenSSL version number into major, minor, ... */

static void tls_version_split(long version, TLS_VINFO *info)
{

/*
 * OPENSSL_VERSION_NUMBER(3):
 * 
 * OPENSSL_VERSION_NUMBER is a numeric release version identifier:
 * 
 * MMNNFFPPS: major minor fix patch status
 * 
 * The status nibble has one of the values 0 for development, 1 to e for
 * betas 1 to 14, and f for release. Parsed OpenSSL version number. for
 * example
 * 
 * 0x000906000 == 0.9.6 dev 0x000906023 == 0.9.6b beta 3 0x00090605f ==
 * 0.9.6e release
 * 
 * Versions prior to 0.9.3 have identifiers  0x0930.  Versions between
 * 0.9.3 and 0.9.5 had a version identifier with this interpretation:
 * 
 * MMNNFFRBB major minor fix final beta/patch
 * 
 * for example
 * 
 * 0x000904100 == 0.9.4 release 0x000905000 == 0.9.5 dev
 * 
 * Version 0.9.5a had an interim interpretation that is like the current
 * one, except the patch level got the highest bit set, to keep continu-
 * ity.  The number was therefore 0x0090581f.
 */

if (version  0x0930) {
info-status = 0;
info-patch = version  0x0f;
version = 4;
info-micro = version  0x0f;
version = 4;
info-minor = version  0x0f;
version = 4;
info-major = version  0x0f;
} else if (version  0x00905800L) {
info-patch = version  0xff;
version = 8;
info-status = version  0xf;
version = 4;
info-micro = version  0xff;
version = 8;
info-minor = version  0xff;
version = 8;
info-major = version  0xff;
} else {
info-status = version  0xf;
version = 4;
info-patch = version  0xff;
version = 8;
info-micro = version  0xff;
version = 8;
info-minor = version  0xff;
version = 8;
info-major = version  0xff;
if (version  0x00906000L)
info-patch = ~0x80;
}
}

/* tls_check_version - Detect mismatch between headers and library. */

voidtls_check_version(void)
{
TLS_VINFO hdr_info;
TLS_VINFO lib_info;

tls_version_split(OPENSSL_VERSION_NUMBER, hdr_info);
tls_version_split(SSLeay(), lib_info);

if (lib_info.major != hdr_info.major
|| lib_info.minor != hdr_info.minor
|| lib_info.micro != hdr_info.micro)
msg_warn(run-time library vs. compile-time header version mismatch: 
 OpenSSL %d.%d.%d may not be compatible with OpenSSL %d.%d.%d,
 lib_info.major, lib_info.minor, lib_info.micro,
 hdr_info.major, hdr_info.minor, hdr_info.micro);
}

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h

[Claus Assmann]

On Mon, Apr 14, 2014, Tom Swirly via RT wrote:

 We'd like to make sure that the libraries we're linking to are up-to-date.

Take a look at the postfix code: tls_check_version().
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: OpenSSL has exploit mitigation countermeasures to make sure its exploitable

[Salz, Rich]

 Recommendation: protect the rest of the private key material.

Yes, we missed some important fields.

Dang is a word that comes to mind.  At least, one I can use in polite company.

/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3310] Can't execute make command

[Maria Moskaleva via RT]

Hello! Make fails, wihle I'm trying build the openssl library.
http://screeny.ru/534bd10369000fff1f0225ce
Why have I problem with md2test.c? (m2test.c:1: parse error before '.'
token)
What should I do? Thanks in advance!

Best regards,
Moskaleva Maria

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3312] OpenSSL :: crypto/mem.c without memset() calls?

[Markus Grundmann via RT]

Hi!

I have checked the current source code of 'crpyto/mem.c' and I'm a
little bit suprised that no memset()-calls are made before the free_*()
functions are entered. I think a zeroing of the previous used memory
is a good solutions to beware for accessing old memory content.

---

$ diff ../../openssl-1.0.1g/crypto/mem.c mem.c (after my modifications)
285a286,288
 if (!str) return;
 else memset(str,0,strlen(str));

293a297,298

 str = NULL;
324a330
 if (ret  num  0) memset(ret,0,num);
328a335,342

 /* Check parameters
  */
 if (!str || !file || line = 0)
 {
return NULL;
 }

330a345
 if (!ret) return NULL;
391a407,409
 if (!str) return;
 else memset(str,0,strlen(str));

396a415
 if (!str) return;
399a419
 str = NULL;


-- 
Best regards,
Markus

Better Privacy with PGP encrypted Mail: http://activezone.de/pgp/
Fingerprint: 58C5 8BAF 6FCE B24F 1881 B5B8 F2A8 E1D0 484B 0054

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: heartbeat RFC 6520 and silently drop behaviour

[Peter Waltenberg]

Not a good idea, particularly with DTLS as it'd be an instant DOS attack.Peter-owner-openssl-...@openssl.org wrote: -To: openssl-dev@openssl.orgFrom: David Jacobson Sent by: owner-openssl-...@openssl.orgDate: 04/14/2014 07:55PMSubject: Re: heartbeat RFC 6520 and silently drop behaviourOn 4/13/14 3:54 AM, Michael Tuexen wrote: On 13 Apr 2014, at 01:54, tolga ceylan tolga.cey...@gmail.com wrote: The RFC has a lot of statements about silently dropping packets in case of various anomalies. But the correct action should be to drop the connection. This would uncover faulty implementations and other bugs that may slide due to 'silently drop' behavior. It'll also make malicious activity a bit more difficult and exposed due to the necessity to reestablish connections for any brute force attempts. What is your opinion on this? There are two MUST discards. One is the the payload being reflected doesn't match, the other is the the payload_length is too large. The second one is the critical one for the heartbleed attack. Let us consider this case. It is clear that you don't respond. You could keep the connection or drop it. When dropping it, you give the attacker an immediate indication that you are not vulnerable. So the attacker can move on. If you don't drop the connection, the attacker has to wait until he decides that the stack is not vulnerable. So it takes more resources on his side. However, the crucial point is to follow the MUST and not send the heartbeat response... Best regards Michael Cheers, Tolga CeylanFirst, dropping the connect does not comply with the RFC, which says that the heartbeat request MUST be silently discarded.Second, it is debatable as to whether dropping the connection is a good idea. First is contrary to Postel's Law: "an implementation should be conservative in its sending behavior, and liberal in its receiving behavior". There may be a coding error in some client and the length is 1 byte too large.  Now that client can't communicate with the server. The client user can't do whatever he wants to do. The server user may be losing business. Neither of these are responsible for the problem nor can they do anything about it. Second, yes, it makes the attacker do a bit more work. But it is very little, and the attacker can run attacks in parallel, so it doesn't make much difference in this throughput. --David Jacobson__OpenSSL Project http://www.openssl.orgDevelopment Mailing Listopenssl-dev@openssl.orgAutomated List Manager  majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org