Opened 18 months ago

Closed 9 months ago

#7215 closed defect (user disappeared)

*** stack smashing detected ***: /usr/sbin/tor terminated on a Raspberry Pi

Reported by: vigdis Owned by:
Priority: normal Milestone: Tor: unspecified
Component: Tor Version:
Keywords: tor-relay debian Cc:
Actual Points: Parent ID:
Points:

Description

Hi,

After I apt-get update && apt-get upgrade my Raspberry Pi, Tor doesn't work any more. What happen is :
root@raspberrypi:/opt/cjdns# /etc/init.d/tor start
* stack smashing detected *: /usr/sbin/tor terminated
/etc/init.d/tor : ligne 111 : 29830 Abandon $DAEMON $VERIFY_ARGS > /dev/null
Checking if tor configuration is valid ... failed!
* stack smashing detected *: /usr/sbin/tor terminated
/etc/init.d/tor : ligne 111 : 29836 Abandon $DAEMON --verify-config 1>&2

On the advice of sysrqb, I put DisableDebuggerAttachment 0 in my torrc file.
Then :
root@raspberrypi:/var/log/tor# gdb tor
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/tor...(no debugging symbols found)...done.
(gdb) r -f /etc/tor/torrc
Starting program: /usr/sbin/tor -f /etc/tor/torrc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x401a74c0 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb) bt
#0 0x401a74c0 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
Cannot access memory at address 0x0
#1 0x401a3ee4 in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
#2 0x4000f250 in ?? () from /lib/ld-linux-armhf.so.3
#3 0xbefff98e in ?? ()
Cannot access memory at address 0x2f006624

My Openssl version is OpenSSL 1.0.1c 10 May 2012 and I have libcrypto.so.1.0.0 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (0x402f2000) and libssl.so.1.0.0 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 (0x402a3000)
apt-cache showpkg libssl-dev gives :
Versions:
1.0.1c-3+rpi1

Child Tickets

Change History (6)

comment:1 Changed 18 months ago by nickm

  • Keywords tor-relay debian added
  • Milestone set to Tor: unspecified

Well, that's pretty weird. My first guess would be some mismatch between the Tor and OpenSSL packages, but I don't know at all what that might be, or why it wouldn't have been noted. OPENSSL_cpuid_setup() is a really basic function for OPENSSL; it shouldn't be able to fail like that.

If it's possible to try building Tor from source, that might make it possible to rule out the idea that it could be a packaging problem. That is, if Tor built from source works, then there's some issue going on with package compatibility. If Tor built from source doesn't work, then we've got a problem in Tor or in the openssl library.

Here's another little test program to tell if your openssl is *completely* broken. If this one crashes, it's definitely OpenSSL's fault. If it doesn't, then the problem might lie somewhere else:

#include <openssl/engine.h>
#include <openssl/evp.h>
#include <openssl/err.h>

int main(int c, char **v)
{
    ERR_load_crypto_strings();
    OpenSSL_add_all_algorithms();
    ENGINE_load_builtin_engines();
    ENGINE_register_all_complete();
    puts("Stuff seems okay.");
    return 0;
}

(It should build okay with "gcc -Wall -lcrypto test.c -o test")

comment:2 Changed 18 months ago by vigdis

Thanks for this quick answer.
I try your test program.
pi@raspberrypi ~ $ gcc -Wall -lcrypto test.c -o test
pi@raspberrypi ~ $ chmod +x test
pi@raspberrypi ~ $ ./test
Stuff seems okay.

I'm going to try to build Tor from source.

comment:3 Changed 18 months ago by vigdis

I compiled it from source. It works. But it's not the same version: Tor version 0.2.4.4-alpha (git-89fc5ed5d6a06127). So I'm not sure that's necessarily a packaging problem.
If needed I can try to build a non-alpha version to see if it works.

comment:4 Changed 18 months ago by nickm

  • Status changed from new to needs_information

Any news here? Right now, it's really smelling like a package compatibility issue to me.

comment:5 Changed 18 months ago by cypherpunks

I forgot my password so I use this account to answer.

So the next day I built from source the stable Tor version and it's working fine. I'm waiting until the next release of Tor to see what happen when I do apt-get upgrade.
I will report here if it worked or not.

comment:6 Changed 9 months ago by nickm

  • Resolution set to user disappeared
  • Status changed from needs_information to closed

No info in 8 months; please re-open if this happens again.

Note: See TracTickets for help on using tickets.