Probleme mit OpenSSL 0.9.8

**ptweety** · 20.06.2006, 08:18

Hallo,

im ds-0.2.6 wird ja openssl-0.9.8a verwendet. Ich habe jetzt versucht einige Anwendungen mit dieser openssl Version zu linken und auszuführen. Dabei habe ich in 3 Fällen jeweils die selben Symptome gesehen: die Anwendung erzeugt hohen cpu load (> 95% verbrauch im top) und kehrt nicht mehr zurück. Passiert ist das nun mit curl, xmail und stunnel.

Ich habe hier im Forum einen link auf ein statisch gelinktes stunnel gefunden und damit hatte ich diese Probleme nicht. Letztes binary war auch mit openssl-0.9.7 gelinkt. Also habe ich mal zum testen meinen ds-mod mit openssl-0.9.7j gebaut und stunnel dagegen gelinkt. Siehe da, es geht nun.

Jetzt die Frage: was ist mit dem openssl im ds-mod los? Kann das jemand reproduzieren? Ist das nur ein lokales Problem wegen der hier (im ds-mod) verwendeten Patches oder könnte das ein Bug in openssl sein? Und was muß getan werden, wenn es wirklich ein Bug ist. Wir können ja nicht auf ewig bei einer openssl-0.9.7er Version bleiben.

Update:

ich habe mal die relevanten Dateien zum Erstellen der fraglichen Anwendungen beigelegt.
nun habe ich einen patch nach dem anderen aus dem openssl build rausgenommen und leider immer das gleiche, negative Ergebnis erzielt. Es klappt nach wie vor nur mit openssl-0.9.7j. Siehe auch untenstehenden curl output. mit openssl-0.9.8{a|b} komme ich nicht über die rote Zeile hinaus.

Code:

# curl -v https://www.bahn.de
* About to connect() to www.bahn.de port 443
*   Trying 81.200.194.40... connected
* Connected to www.bahn.de (81.200.194.40) port 443
* SSL: couldn't set callback!
* successfully set certificate verify locations:
*   CAfile: /usr/share/curl/curl-ca-bundle.crt
  CApath: none
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*        subject: /C=DE/ST=Berlin/L=Berlin/O=DB Systems GmbH/OU=DB AG/OU=Terms o
f use at www.verisign.com/rpa (c)00/CN=www.bahn.de
*        start date: 2006-01-11 00:00:00 GMT
*        expire date: 2007-01-11 23:59:59 GMT
*        common name: www.bahn.de (matched)
*        issuer: /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign Interna
tional Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.
(c)97 VeriSign
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.15.4 (mipsel-unknown-linux-gnu) libcurl/7.15.4 OpenSSL/0.9.
7j zlib/1.2.3
> Host: www.bahn.de
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Tue, 20 Jun 2006 08:42:35 GMT
< Server: Apache
< Location: https://www.bahn.de/-S:PtVOSN:eWrAK9NNZrTV5tNNNQxM/p/view/index.shtm
l
< Transfer-Encoding: chunked
< Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head><title>302 Found</title></head> <body><h1>Found</h1>
The document has moved <A HREF="https://www.bahn.de/-S:PtVOSN:eWrAK9NNZrTV5tNNNQ
xM/p/view/index.shtml">here</A>.<P>
 <hr /> <address>Apache Server at www.bahn.de Port 443</address>
</body></html>* Connection #0 to host www.bahn.de left intact
* Closing connection #0

MFG pTweety

**danisahne** · 20.06.2006, 13:53

Das hört sich ja sehr nach dem Problem an, das auch OpenVPN hat. Vielleicht gibt es sicherheitsrelevante Unterschiede zwischen den OpenSSL Versionen?

**ptweety** · 20.06.2006, 16:09

Zitat von danisahne

Das hört sich ja sehr nach dem Problem an, das auch OpenVPN hat. Vielleicht gibt es sicherheitsrelevante Unterschiede zwischen den OpenSSL Versionen?

Tja, das kann ich leider nicht beurteilen. EDIT: Aber zumindest hat jspies hier erfolgreich mit openssl-0.9.8b compiliert. Das deckt sich ja nicht mit meinen Erfahrungen. Evtl. hat er einfach nur die korrekten Einstellungen im openssl.mk gesetzt

Ich habe aber auch gute Nachrichten, denn nach einem Downgrade von openssl auf 0.9.7f und neuflashen der Firmware scheint alles zu tun. Insbesondere xmail kann jetzt (zusammen mit meinem TheBat!) STARTTLS:

Code:

 20.06.2006, 15:53:43: FETCH - Empfange Nachrichten
 20.06.2006, 15:53:45: FETCH - Einleitung TLS-Handshake
>20.06.2006, 15:53:45: FETCH - Zertifikat S/N: 0, Algorithmus: RSA (2048 Bits), ausgestellt von 18 Jun 2006 bis 17 Jun 2010, für 5 Host(s): localhost, fritz.box, mail.fritz.box, ptweety.net, ptweety.selfip.net.
>20.06.2006, 15:53:45: FETCH - Besitzer: de, Germany, Frankfurt, pTweety, localhost, fritz.box, mail.fritz.box, ptweety.net, ptweety.selfip.net.
>20.06.2006, 15:53:45: FETCH - Dieses Zertifikat wurde selbst ausgestellt.
 20.06.2006, 15:53:46: FETCH - TLS-Handshake vollständig
 20.06.2006, 15:53:46: FETCH - Verbunden mit dem POP3-Server
 20.06.2006, 15:53:46: FETCH - bestätigt (APOP-MD-5)
 20.06.2006, 15:53:46: FETCH - 0 Nachrichten in der Mailbox, 0 neu
 20.06.2006, 15:53:46: FETCH - Verbindung beendet - 0 Nachrichten empfangen
 20.06.2006, 15:54:07: SEND  - Sende Nachricht(en) - 1 Nachrichten in der Warteschlange
 20.06.2006, 15:54:09: SEND  - Einleitung TLS-Handshake
>20.06.2006, 15:54:09: SEND  - Zertifikat S/N: 0, Algorithmus: RSA (2048 Bits), ausgestellt von 18 Jun 2006 bis 17 Jun 2010, für 5 Host(s): localhost, fritz.box, mail.fritz.box, ptweety.net, ptweety.selfip.net.
>20.06.2006, 15:54:09: SEND  - Besitzer: de, Germany, Frankfurt, pTweety, localhost, fritz.box, mail.fritz.box, ptweety.net, ptweety.selfip.net.
>20.06.2006, 15:54:09: SEND  - Dieses Zertifikat wurde selbst ausgestellt.
 20.06.2006, 15:54:10: SEND  - TLS-Handshake vollständig
 20.06.2006, 15:54:10: SEND  - verbunden mit dem SMTP-Server
 20.06.2006, 15:54:10: SEND  - authentifizieren (Software CRAM-MD5)...
 20.06.2006, 15:54:10: SEND  - Sende Nachricht an me@ptweety.net
<20.06.2006, 15:54:10: SEND  - Nachricht an me@ptweety.net versandt (474 Bytes)
 20.06.2006, 15:54:10: SEND  - Verbindung beendet - 1 Nachrichten versandt

Und zusammen mit stunnel sollte dann TLS auch kein Problem mehr darstellen. Edit: denkste. Nur die erste Verbindung läuft gut. Danach keine Antwort mehr auf dieser Leitung

MFG pTweety

**knox** · 22.06.2006, 12:14

ich verwende ebenfalls openssl 0.9.8b

vielleicht hilft das weiter?

UPDATE2: nutzloses aus beitrag entfernt.

**ptweety** · 03.07.2006, 13:42

Zitat von knox

vielleicht hilft das weiter?

Leider nicht.

BTW: 'tschuldigung für die späte Reaktion. Ich hatte die Tage mit ds-0.2.7 und Fußball schaun zu tun und kam daher nicht eher zum Testen.

MFG pTweety

**olistudent** · 03.07.2006, 19:12

Seltsam, im Openwrt wird ja auch openssl-0.9.8b genommen.
Wo liegt der Fehler jetzt?
Am openvpn wohl nicht, sonst hätte man das schon irgendwo gelesen.
Bleibt noch unsere Toolchain/uClibc?

MfG Oliver

edit: Ich komm auch nicht weiter...

Code:

/var/mod/root # ./curl -v https://www.bahn.de
* About to connect() to www.bahn.de port 443
*   Trying 81.200.194.40... connected
* Connected to www.bahn.de (81.200.194.40) port 443
/var/mod/root #

**ptweety** · 03.07.2006, 23:58

Zitat von olistudent

Wo liegt der Fehler jetzt?

edit: Ich komm auch nicht weiter...

Ich bin mit meinem Latein am Ende. Ich weiß nur, dass es mit 0.9.7 funktioniert und mit 0.9.8 nicht. Es gibt keinen segfault oder sonst einen Fehler. Nur die Programme drehen durch und saugen alle CPU-Zeit auf.

MFG pTweety

**knox** · 02.08.2006, 13:56

ich dachte lange zeit, bei mir funktioniert das openssl einwandfrei. zumindest in verbindung mit openvpn...

inzwischen habe ich bemerkt, dass ich die selben probleme habe und das ist wirklich sehr bedauerlich. anscheinend habe ich eine ganze zeit lang die openssl libs von jspies in meinen images gehabt und daher die probleme "übersehen"

es wäre sehr gut, wenn leute mit mehr ahnung als ich der sache auf den grund gehen könnten.

@jspies:
da du der einzige bist, der eine funktionale openssl 0.9.8 lib erstellen konnte, setze ich auf dich besondere hoffnungen

@danisahne
vielleicht ist es ein sinnvoller workarround, die 0.9.7 mit ins mod zu nehmen, bis die sache geklärt werden konnte?

**jspies** · 04.08.2006, 09:31

Zitat von knox

...
@jspies:
da du der einzige bist, der eine funktionale openssl 0.9.8 lib erstellen konnte, setze ich auf dich besondere hoffnungen

...

Warum es ausgerechnet bei mir klappt, kann ich auch nicht mit letzter Sicherheit sagen.
Ich habe hier mal meine Konfiguration beschrieben.
Vielleicht kann jemand mal versuchen, damit die Libs zu bauen und zu testen. Wenn die es dann auch nicht tun, dann haben wir ein Problem und ich muss sehr sorgfältig auf meinen Rechner achten.

MfG Jürgen

**knox** · 08.08.2006, 22:59

zur zeit experimetiere ich damit herum, die ssl libs von jspies mit ins image zu stecken und bin dabei auf einen sehr sonderbaren fall gestoßen:

+ ssl libs von jspies im image (unter /usr/lib)

Code:

Tue Aug  8 22:49:19 2006 us=149000 OpenVPN 2.1_beta14 mipsel-linux [SSL] [LZO2] built on Jul 24 2006
Tue Aug  8 22:49:20 2006 us=909000 Diffie-Hellman initialized with 2048 bit key
Tue Aug  8 22:49:20 2006 us=919000 WARNING: file '/var/tmp/vpn/fritzbox.key' is group or others accessible
Tue Aug  8 22:49:20 2006 us=939000 TLS-Auth MTU parms [ L:1590 D:138 EF:38 EB:0 ET:0 EL:0 ]
...
Tue Aug  8 22:49:50 2006 us=999000 192.168.x.y:1194 TLS: Initial packet from 192.168.x.y:1194, sid=a16f97e4 00ccee04
Tue Aug  8 22:49:53 2006 us=779000 192.168.x.y:1194 VERIFY OK: depth=1, /C=DE/ST=xxxx/L=xxxx/O=xxxx/CN=ca/emailAddress=xxxx@xxxx.xxx
Tue Aug  8 22:49:53 2006 us=799000 192.168.x.y:1194 VERIFY OK: depth=0, /C=DE/ST=xxxx/L=xxxx/O=xxxx/CN=ca/emailAddress=xxxx@xxxx.xxx
Segmentation fault

+ die selben libs zusätzlich unter /var/tmp/vpn
+ export LD_LIBRARY_PATH=/var/tmp/vpn

Code:

Tue Aug  8 22:52:31 2006 us=29000 OpenVPN 2.1_beta14 mipsel-linux [SSL] [LZO2] built on Jul 24 2006
Tue Aug  8 22:52:34 2006 us=49000 Diffie-Hellman initialized with 2048 bit key
Tue Aug  8 22:52:34 2006 us=59000 WARNING: file '/var/tmp/vpn/fritzbox.key' is group or others accessible
Tue Aug  8 22:52:34 2006 us=79000 TLS-Auth MTU parms [ L:1590 D:138 EF:38 EB:0 ET:0 EL:0 ]
...
Tue Aug  8 22:52:34 2006 us=359000 192.168.x.y:1194 TLS: Initial packet from 192.168.x.y:1194, sid=729159a3 e17adc28
Tue Aug  8 22:52:38 2006 us=519000 192.168.x.y:1194 VERIFY OK: depth=1, /C=DE/ST=xxxx/L=xxxx/O=xxxx/CN=ca/emailAddress=xxxx@xxxx.xxx
Tue Aug  8 22:52:38 2006 us=549000 192.168.x.y:1194 VERIFY OK: depth=0, /C=DE/ST=xxxx/L=xxxx/O=xxxx/CN=ca/emailAddress=xxxx@xxxx.xxx
Tue Aug  8 22:52:41 2006 us=639000 192.168.x.y:1194 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Aug  8 22:52:41 2006 us=649000 192.168.x.y:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug  8 22:52:41 2006 us=649000 192.168.x.y:1194 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Aug  8 22:52:41 2006 us=659000 192.168.x.y:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug  8 22:52:41 2006 us=679000 192.168.x.y:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Aug  8 22:52:41 2006 us=689000 192.168.x.y:1194 [client] Peer Connection Initiated with 192.168.x.y:1194

ich verstehe das ganz und gar nicht

der einzige unterschied, den ich finden kann, liegt schließlich darin, wo sich die libs befinden?!

**knox** · 11.08.2006, 19:13

inzwischen ist es mir gelungen, die libs á la jspies nachzubauen! mit den libs funktioniert auch das curl von ptweety (s.o.).

nur damit habe ich leider genau das selbe problem: libs unter /usr/lib = segfault, exakt die selben libs in /var/tmp = alles ok.

eine andere frage bleibt, worin der entscheidende unterschied zum openssl.mk aus dem dsmod liegt? ein diff anbei (ich versteh davon nix).

update: veraltete dateianhänge entfernt, siehe folgende beiträge.

**knox** · 25.08.2006, 11:11

gestern habe ich testweise das makefile für openssl 0.9.7i aus dem svn von openwrt genommen, für 0.9.7j angepasst und in das ds-0.2.9 hineingefummelt. die auf diese weise erzeugten libs verursachen die selben probleme wie 0.9.8b.

es hat also anscheinend nichts mit der openssl version zu tun, sondern mit den details beim build vorgang. kann denn wirklich keiner helfen?

@daniel
bezug nehmend auf den versuch, "funktionierende" libs ins image einbauen:
wie kann es sein, dass exakt die selben dateien aus dem ram (/var/tmp) funktionieren, während sie aus dem rom (/usr/lib) zum segfault führen?

**danisahne** · 25.08.2006, 11:15

Zitat von knox

wie kann es sein, dass exakt die selben dateien aus dem ram (/var/tmp) funktionieren, während sie aus dem rom (/usr/lib) zum segfault führen?

Das weiß ich allerdings auch nicht.

**knox** · 30.08.2006, 00:01

wieder einen schritt weiter: offensichtlich sind in der neusten original firmware openssl libs enthalten.

Code:

./build/original/filesystem/lib/libcrypto.so.0.9.8
./build/original/filesystem/lib/libcrypto.so.1
./build/original/filesystem/lib/libcrypto.so
./build/modified/filesystem/usr/lib/libcrypto.so.0.9.8
./build/modified/filesystem/usr/lib/libcrypto.so
./build/modified/filesystem/lib/libcrypto.so.0.9.8
./build/modified/filesystem/lib/libcrypto.so.1
./build/modified/filesystem/lib/libcrypto.so

das ds-mod hat "seine" ssl libs unter /usr/lib, aber die werden anscheinend gar nicht geladen. und wenn man den LD pfad anpasst, dann klappts auch mit den libs im rom, nicht nur im ram...

update: wenn man die ssl libs á la jspies nach root/lib/ legt und dann ein image erstellt, funktioniert danach auf der box sowohl openvpn mit certs als auch das curl vom anfang dieses threads

fazit: noch ein bisschen gefummel am openssl.mk und die sache sollte endlich aus der welt sein.

**knox** · 06.09.2006, 18:25

seit gestern ist eine sicherheitslücke in openssl bekannt, die auch die bisher verwendete version 0.9.8b betrifft. weitere details dazu findet man u.a. im OpenSSL Security Advisory vom 5. september.

ich habe daher die neue 0.9.8c auf die jspies-art erstellt und angehängt.

update: veraltete dateien entfernt. siehe nachfolgender beitrag.

**knox** · 20.09.2006, 23:47

dank olistudent kann dieser thread geschlossen werden

die lösung des ursprünglichen problems ist durch folgende änderung an der make/libs/openssl.mk zu erreichen:

Code:

TARGET_CFLAGS:=-Os -Wa,--trap -pipe -mips2 -Wall -W

damit es auch mit einem original firmware image für die 7170 funktioniert, in dem avm eigene ssl libs enthalten sind, kann man folgendes ins ds-mod verzeichnis unter patches/230-openssl.sh einfügen:

Code:

if [ "$DS_LIB_libcrypto" == "y" ]
then
	[ "$DS_VERBOSITY_LEVEL" -ge 1 ] && echo "${L1}removing avm's libcrypto"
	rm -f "${FILESYSTEM_MOD_DIR}/lib/libcrypto.so"
	rm -f "${FILESYSTEM_MOD_DIR}/lib/libcrypto.so.1"
	rm -f "${FILESYSTEM_MOD_DIR}/lib/libcrypto.so.0.9.8"
fi
if [ "$DS_LIB_libssl" == "y" ]
then
	[ "$DS_VERBOSITY_LEVEL" -ge 1 ] && echo "${L1}removing avm's libssl"
	rm -f "${FILESYSTEM_MOD_DIR}/lib/libssl.so"
	rm -f "${FILESYSTEM_MOD_DIR}/lib/libssl.so.1"
	rm -f "${FILESYSTEM_MOD_DIR}/lib/libssl.so.0.9.8"
fi

ich habe das ganze als patch beigefügt, damit es leicht auf eine frische ds-0.2.9 installation angewendet werden kann.

für alle, die nicht selber compilen wollen, außerdem frische openssl 0.9.8c libraries im ds-mod stil zum einfachen einfügen in eigene images. sind übrigens bedeutend kleiner als die im jspies-stil

update: inzwischen wurde ein neue version von openssl veröffentlicht. die hier angehängten dateien wurden entfernt, die neuste version weiter hinten in diesem thread angefügt.

**olistudent** · 21.09.2006, 09:57

Hats wirklich daran gelgen. Ich wollte es gar nicht glauben. 5 Stunden lang hab ich openssl kompiliert. Irgendwann hab ich aufgehört zu zählen und dann liegts an einem cflag...
Jetzt ist auch klar warum das im Openwrt funktioniert.

MfG Oliver

**knox** · 29.09.2006, 10:08

es wurde wieder ein update für openssl veröffentlicht, das einige sicherheitslücken schließt! weitere details findet man im openssl security advisory vom 28.9.2006.

ich habe die bibliotheken neu übersetzt und angefügt. auch den weiter oben beschriebenen patch habe ich aktualisiert.

update: veraltete dateien entfernt, benutze die suchfunktion.

**DPR** · 25.11.2006, 00:12

Zitat von ptweety

Und zusammen mit stunnel sollte dann TLS auch kein Problem mehr darstellen. Edit: denkste. Nur die erste Verbindung läuft gut. Danach keine Antwort mehr auf dieser Leitung

MFG pTweety

Ist zwar schon etwas älter der Thread, trotzdem versuch ich's mal ...

Ich habe genau dasselbe Problem mit ds-mod-0.2.9, stunnel 4.16, OpenSSL 0.9.8d ... die erste Verbindung klappt. Sobald der Client aber die Verbindung schließt, geht auf der Seite der Fritz!Box irgendwas schief. Der Client erkennt die Verbindung als getrennt, der Server zeigt in netstat den Port aber nach wie vor als "established" an.

Ich vermute, dass das eher ein Bug in stunnel ist, als in der OpenSSL lib. Habt ihr da irgendwelche Erfahrungen, bzw. gibt es neue Erkenntnisse zu dem Thema ?

**DPR** · 07.12.2006, 20:13

Ok, ich habe mal wieder etwas Zeit gefunden an dem Problem zu arbeiten und hab es auch behoben ! Es lag eindeutig am Threading-Modell. Kaum hab ich das auf das normale forking umgestellt, funktioniert alles einwandfrei. Wäre super, wenn stunnel seinen Weg ins ds-mod finden würde.

Thema: Probleme mit OpenSSL 0.9.8

Themen-Optionen

Anzeige

Probleme mit OpenSSL 0.9.8

immer noch probleme mit openssl 0.9.8

sicherheitslücke in openssl-0.9.8b

gelöst

Sicherheitsupdate openssl-0.9.8d

Ähnliche Themen

OpenSSL - Fehler bei der Kompilierung

make of openssl fails

OpenSSL Konfiguration von AVM erraten

OpenSSL 0.9.8d kompilieren

Openssl

Berechtigungen