Hello
Some news: The "post mortem data dumps" are working good now. We try since one week to exploit the notes buffer overglow. But i think now that it's not really feasible to use the buffer overflow in the notes feature: - the link string is processed by a UTF8 encoder (we can see this in the cache dumps) before doing the overflow - the string (and some sucessive copies) is stored probably in the heap (malloc) - the overflow probably happens because of the filesystem unable to handle too long filenames. - we can put a return addr, but not one in the buffer. The processor jumps at this addr (has been checked !) - we could probably find some useful opcodes that fit the UTF8 codes - we now code every char with %xx (html link encoding spec) for avoiding side effects from some special values like " which close the link but the addr of the buffer is 09D7mmnn. We cannot put this D7, so we cannot jump to our buffer :( (as it's little endian, the string would be in the order : nn mm D7 09) I tried to move the buffer by adding long data, does not work. I think we will need another vulnerability. there are probably many, in the itunes DB, mp3 play, vcards parsing, etc etc etc... someone has an idea ? sto what the utf8 parser does : link : mem values 01 : 01 ... 7F : 7F 80 : 80 c2 81 : 81 c2 83 : 82 c2 ... BF : bf c2 C0 : 80 c3 C1 : 81 c3 ... CF : 8f c3 D0 : 90 c3 ... DF : 9f c3 E0 : a0 c3 ... F0 : b0 c3 entering already formed UTF8 just reencodes each byte into utf again... _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
