Buffer Overflow SIGILL debugging¶
- Buffer Overflow SIGILL debugging
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 0x2see attached logifiles, crash is not timestamped
- see segfault crash(trapped) in 1st installtion log, 7min delay to previous log entry
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.
- extensive logging, e.g. every function call into a circular log, to prevent overspill (see logread)
- 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¶
- -fstack-protector-all to gcc
- 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