Buffer Overflow SIGILL debugging

problem summary

we observed SIGILL' on two different installations so far.
both installation are old dss (sd-card)
problem seems to occur with 1.7 release
the 2 core dumps (same installation), contain no stack trace, "Can not access memory at adress 0x2"

Core was generated by `/usr/bin/dss --prop:/config/jslogdirectory=/var/log/dss/js --prop:/system/versi'.
Program terminated with signal 4, Illegal instruction.
#0  0x41365508 in ?? ()
(gdb) thread apply all bt
Cannot access memory at address 0x2
see attached logifiles, crash is not timestamped
  • see segfault crash(trapped) in 1st installtion log, 7min delay to previous log entry

installed javascript apps

system add-ons: anwesenheit, benutzerdef. handlungen, scene responder, verbrauchsanzeige, zeitschaltuhr

installation installed custom apps ver
1st auto off, eragy meter, nambu meter, ds Doku 1.7
2nd auto off, benachrichtigung, bidgely meter, dim wizard, mobile remote, nambu meter, ds Doku 1.7
3rd auto-off event-mailer event-twitterer led-wizard mobile-remote-control motion-detector myenersave-meter nambu-meter remote-connectivity 1.8

TODO / in progress

  • stack protector, pending merge request for dss, TBD enable for OE / also for dependent libraries
  • running mtest on returned item.
  • remove anrmalloc, switch back to std libc
  • git log origin/R1.6..origin/R1.7, review
  • log every event processed (eventinterpreter), install trap for sigill(timestamp for sigill)
    • overwriting the default handler, suppresses creation of core dump

Analysis / Guesses

  • hw corruption is unlikely due to 2 different installations and dependency on dSS version
  • code page is r/o
  • buffer overflow on the stack, corrupted return address (likely)
  • spidermonkey' a jit compiler generated faulty code
  • a zillion other reasons.

ideas:

input recorder

Problem is that the crash happens ratherely and evtl. depends on the installation.
If we could trace all events going into the dSS, we could reproduce the internal state of the dSS at any time.

This log together with some type of replay mechanism, the developer could reproduce the crash many times,
and interactively either increase the debugging output, or try different versions of the binary (git bisect).

instrumention/hardening of dSS binary

stack protection

http://wiki.osdev.org/GCC_Stack_Smashing_Protector
  • -fstack-protector-all to gcc
http://security.stackexchange.com/questions/24444/what-is-the-most-hardened-set-of-options-for-gcc-compiling-c-c
  • same as above but set lower limit for arrays to be protected, see ssp-buffer-size

see also Memory_Profilers

Protect elf sections

  • set no-execute flag on stack
  • try to make GOT read/only / prelinking

installation2_logfiledss.txt Magnifier (3.14 MB) Andreas Fenkart, 06/20/2013 01:13 PM

installation1_crashes_only.txt Magnifier (2.39 KB) Andreas Fenkart, 06/20/2013 01:13 PM