Re: [openssl-users] glibc detected *** xxx: double free or corruption (!prev): 0x097b8750

[Vikas TM]

Hi Matt,

It looks like handling crypto lock mechanism issue. I defined NO SRP. Now I
am getting segmentation fault in CRYPTO_add_lock() function referencing
NULL pointer. Please find GDB output below,

(gdb) run ftp://x.x.x.x:sample.txt

Starting program: /App/vikftp ftp://x.x.x.x:sample.txt

Missing separate debuginfo for /lib/ld-linux.so.2

Missing separate debuginfo for /lib/libdl.so.2

Missing separate debuginfo for /lib/libpam.so.0

Missing separate debuginfo for /lib/libm.so.6

Missing separate debuginfo for /lib/libc.so.6

Missing separate debuginfo for /lib/libaudit.so.0

process 22287 is executing new program: /App/vikftp

Missing separate debuginfo for /lib/ld-linux.so.2

Missing separate debuginfo for /lib/libdl.so.2

Missing separate debuginfo for /lib/libpam.so.0

Missing separate debuginfo for /lib/libm.so.6

Missing separate debuginfo for /lib/libc.so.6

Missing separate debuginfo for /lib/libaudit.so.0



Program received signal SIGSEGV, Segmentation fault.

0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3,
file=0x85d0030 "/102d/s/tasn_utl.c", line=118)

at /102d/s/cryptlib.c:624

624 ret = *pointer + amount;

(gdb) bt

#0  0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3,
file=0x85d0030 "/102d/s/tasn_utl.c", line=118)

at /102d/s/cryptlib.c:624

#1  0x08249d2a in asn1_do_lock (pval=0xff8eee90, op=-1, it=0x862cb1c) at
/102d/s/tasn_utl.c:118

#2  0x08246ed5 in asn1_item_combine_free (pval=0xff8eee90, it=0x862cb1c,
combine=0) at /102d/s/tasn_fre.c:146

#3  0x08246c40 in ASN1_item_free (val=0x1001, it=0x862cb1c) at
/102d/s/tasn_fre.c:72

#4  0x0825eeea in X509_free (a=0x1001) at /102d/s/x_x509.c:143

#5  0x082ee677 in ssl_cert_clear_certs (c=0x872e4e0) at
/102d/s/ssl_cert.c:431

#6  0x082ee7ed in ssl_cert_free (c=0x872e4e0) at /102d/s/ssl_cert.c:489

#7  0x0822f926 in SSL_free (s=0x872e340) at /102d/s/ssl_lib.c:627

#8  0x0816566c in closeConnection (pcx=0x86d8310, rsn=0x0, graceful=1
'\001') at /App/vikftp.c:10098

Please let me know if you have any solution.
Thanks & Regards,
Vikas
On 7 Apr 2016 7:18 pm, "Vikas TM"  wrote:

Hi Matt,

I was trying the patches available in the Internet. Due to that few blank
lines might have added or removed. But no major change in the code.

Thanks & Regards,
Vikas
On 7 Apr 2016 7:07 pm, "Matt Caswell"  wrote:

>
>
> On 07/04/16 14:23, Vikas TM wrote:
> > Hi Mike
> >
> >
> > I have integrated openSSL version 102d. While running secure FTP
> > connection, I have encountered double free or corruption issue.
>
> Are you running 1.0.2d as downloaded from the OpenSSL website with no
> other patches applied? The line numbers below do not match up with the
> git copy of 1.0.2d.
>
> Matt
>
> >
> > The TLS negotiation is successful and file is also getting transferred
> > to partner machine. At the end while freeing all the memory, file
> > transfer is ended with “double free or corruption issue”. I have tried
> > almost all the patch available in internet. Please let me know if you
> > any solution.
> >
> >
> >
> > Machine: Linux x86_64
> >
> > Please find the GDB output below,
> >
> >
> >
> > Breakpoint 1, ssl3_free (s=0x8736430) at /102d/s/s3_lib.c:2995
> >
> > 2995if (s == NULL || s->s3 == NULL)
> >
> > (gdb) n
> >
> > 3009ssl3_cleanup_key_block(s);
> >
> > (gdb)
> >
> > 3010if (s->s3->rbuf.buf != NULL)
> >
> > (gdb)
> >
> > 3011ssl3_release_read_buffer(s);
> >
> > (gdb)
> >
> > 3012if (s->s3->wbuf.buf != NULL)
> >
> > (gdb)
> >
> > 3013ssl3_release_write_buffer(s);
> >
> > (gdb)
> >
> > 3014if (s->s3->rrec.comp != NULL)
> >
> > (gdb)
> >
> > 3017if (s->s3->tmp.dh != NULL)
> >
> > (gdb)
> >
> > 3021if (s->s3->tmp.ecdh != NULL)
> >
> > (gdb)
> >
> > 3025if (s->s3->tmp.ca_names != NULL)
> >
> > (gdb)
> >
> > 3027if (s->s3->handshake_buffer) {
> >
> > (gdb)
> >
> > 3030if (s->s3->handshake_dgst)
> >
> > (gdb)
> >
> > 3031ssl3_free_digest_list(s);
> >
> > (gdb)
> >
> > 3033if (s->s3->alpn_selected)
> >
> > (gdb)
> >
> > 3038SSL_SRP_CTX_free(s);
> >
> > (gdb)
> >
> >
> >
> > 3042OPENSSL_cleanse(s->s3, sizeof *(s->s3));
> >
> > (gdb) n
> >
> > 3047OPENSSL_free(s->s3);
> >
> > (gdb) p *(s->s3)
> >
> > $1 = {flags = 1447178013, delay_buf_pop_ret = -1332182677, read_sequence
> > = "\311\343\376\032\067Ut\224", read_mac_secret_size = -557140059,
> >
> >   read_mac_secret = "\363\t
> >
> 8Qk\206\242\277\335\377\034-?Rf{\221\253\300\337\353\016*Ge\204\244\265\307\332\363\003\031\060Ha{\226\262\317\355\f,=Obv\213\241\270\320\356\003\036:Wu\224\264\305\327\356\374",
> > write_sequence = "\023)@Xq\213\246", ,
> > write_mac_secret_size = 1008532959,
> >
> >   write_mac_secret =
> >
> 

Re: [openssl-users] is 1.0.2g meant to be buildable ? missing rc4_md5_enc implementation !

[Jason Vas Dias]

Thanks Jakob -
But running the rc4-x86_64.pl script, even if by a Makefile, does not define
the function either :

$ ./rc4-x86_64.pl  > ../rc4-md5-x86_64.s
$ cd ..
$ as -o rc4-md5-x86_64.o rc4-md5-x86_64.s
$ nm rc4-md5-x86_64.o
 U OPENSSL_ia32cap_P
 T RC4
0720 T RC4_options
0660 T private_RC4_set_key

Do I need to pass 'no-asm' to Configure ?

The Configure command I used was :

$ LIBDIR=/usr/lib64 ./Configure --prefix=/usr threads shared
linux-x86_64:gcc $CFLAGS_64 2>&1 | tee configure.log

configure.log attached.

And I did run 'make depend' - log attached.

I used the command:

$ make -j4 2>&1 | tee make.log

to build OpenSSL and there is no occurence of the text ' rc4-x86_64' anywhere in
that (v.large) log file , indicating no attempt was made to generate
ASM for x86_64 ?

Please, for practical everyday use, what is the latest / best stable OpenSSL ?
1.0.1s or 1.0.2g ?

The last one I used extensively was 1.0.1g - but I'd like to build the
latest stable release now.

Thanks & Regards, Jason



On 06/04/2016, Jakob Bohm  wrote:
> No, that script is run by the Makefile if relevant.
>
> Given what others have reported recently, please check
> what arguments you passed to config or configure (before
> running make).
>
> Also remember to do make depend.
>
> On 06/04/2016 22:58, Jason Vas Dias wrote:
>> Aha! I just saw rc4-md5-x86_64.pl - am I meant to run this manually to
>> produce the ASM
>> to compile to produce the object ? Why wasn't this run as part of the
>> build ?
>> I am building with perl-5.22.1 , gcc-5.3.0, make-4.1 on Linux x86_64 LFS
>> .
>>
>>
>> On 06/04/2016, Jason Vas Dias  wrote:
>>> please can anyone tell me:
>>> Is the 1.0.2g release from :
>>> http://www.openssl.org/source/openssl-1.0.2g.tar.gz
>>> meant to build ? Is this meant to be the latest stable release , or is
>>> that 1.0.1s ?
>>> The 1.0.2g release does not build, for the linux-x86_64:gcc 'threads
>>> shared' configuration
>>> (or any other AFAICS) because it lacks an implementation of
>>> rc4_md4_enc() - there
>>> are calls to it in crypto/evp/e_rc4_hmac_md5.c , but no definition of it
>>> :
>>>
>>> $ grep -RIn --include '*.[ch]' rc4_md5_enc
>>> crypto/evp/e_rc4_hmac_md5.c:80:void rc4_md5_enc(RC4_KEY *key, const
>>> void *in0, void *out,
>>> crypto/evp/e_rc4_hmac_md5.c:144:rc4_md5_enc(>ks, in +
>>> rc4_off, out + rc4_off,
>>> crypto/evp/e_rc4_hmac_md5.c:188:rc4_md5_enc(>ks, in +
>>> rc4_off, out + rc4_off,
>>> $ make
>>> ...
>>> $ ( LIBDEPS="${LIBDEPS:--L.. -lssl  -L.. -lcrypto }";
>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
>>> -march=x86-64 -mtune=native -O2 -g -fPIC -pipe }"; LIBPATH=`for x in
>>> $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;
>>> LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; set -x;
>>> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
>>> ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o
>>> dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o
>>> rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o
>>> gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o
>>> s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
>>> pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
>>> rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
>>> + LD_LIBRARY_PATH=..:
>>> + gcc -DOPENSSL_THREADS -march=x86-64 -mtune=native -O2 -g -fPIC -pipe
>>> -o openssl openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o
>>> enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
>>> rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
>>> genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
>>> s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
>>> pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o
>>> engine.o ocsp.o prime.o ts.o srp.o -L.. -lssl -L.. -lcrypto
>>> ../libcrypto.a(e_rc4_hmac_md5.o): In function `rc4_hmac_md5_cipher':
>>> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:144:
>>> undefined reference to `rc4_md5_enc'
>>> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:188:
>>> undefined reference to `rc4_md5_enc'
>>> collect2: error: ld returned 1 exit status
>>>
>>> ie. the make fails because nowhere in any library or object file is
>>> that function defined -
>>> I have checked this with nm .
>>>
>>> I guess my answer is that ! should be building 1.0.1s ?
>>>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

Re: [openssl-users] good riddance to PayPal

[Steve Marquess]

On 05/05/2016 04:41 PM, Steve Marquess wrote:
> We've had a PayPal account for years, as the most convenient way for
> individuals to send small donations. However, as the person who has
> managed that account I can attest that PayPal has always been rather
> annoying to deal with, and I've finally hit my limit. I'm in the process
> of closing that account (something PayPal makes unnecessarily difficult
> and protracted). I was able to refund most of the recent donations that
> we were unable to recover, leaving a balance of $259.45 that will either
> be forfeited to PayPal or (hopefully) refunded by them back to the
> original donors.
> 
> The PayPal donate link ("button") on our web site has been removed. I've
> asked PayPal to block any future inbound transactions while we fight
> over the account closure, but can't be confident that was done. Please
> do not donate via PayPal to any account claiming to represent us; such
> donations won't go to us and may not ever be returned to you.
> 
> This closure of the only convenient means of receiving small donations
> does not mean that we do not value such donations. Those of you who have
> donated via PayPal, many via recurring donations, have our gratitude and
> thanks. I regret that there is no clear alternative to switch to instead
> (suggestions welcome if there are options I'm unaware of).
> 
> -Steve M.
> 

After another half hour of "your call is important to us" recordings, I
have apparently succeeded in closing our PayPal account. I was promised
that the 29 donations totaling $258.48 that I was unable to either
withdraw or refund will be refunded directly by PayPal.

Thanks again to all the donors who have support OpenSSL, via PayPal or
other means. I'm looking into alternatives for account free online
payments, so far without success.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
20-22 Wenlock Road
London N1 7GU
United Kingdom
+44 1785508015
+1 301 874 2571 direct
marqu...@opensslfoundation.org
ste...@openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Attack of the FIPS 140-2 Clones

[Steve Marquess]

If you neither know nor care what FIPS 140-2 is, count yourself lucky
and move on (even if you're a Star Wars fan; this isn't nearly as
entertaining).

The "Alternative Scenario 1A/1B" aka "clone" aka "rebrand" validations
have been an endless source of confusion, even for the accredited test
labs and the CMVP. The one bright spot is that these clone validations
indirectly expand the number of formally tested platforms ("Operational
Environments" in FIPS-speak) available to all OpenSSL FIPS Object Module
users.

I've added a new section, 2.10, to the OpenSSL FIPS User Guide that
summarizes this set of platforms:

  https://www.openssl.org/docs/fips/UserGuide-2.0.pdf

As of today there are nine such clone validations, in addition to the
ancestral #1747 validation all are derived from. Collectively they cover
178 unique platforms which are listed in alphabetical order in table 2.10b.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users