[elinks-dev] festival command injection when PIPE_BUF < 1037
The dangling pointer crash has been fixed, thanks to Witek. However, I think there is another problem in write_to_festival. When FESTIVAL_SYSTEM is being used, write_to_festival generates a string that contains a SayText function call with the quoted text as an argument. Because write_to_festival restricts the original line to 512 characters, the resulting string can have at most 13+512*2 = 1037 characters. This is greater than 512, which SUSv2 specifies as the minimum allowed value of PIPE_BUF. So, on systems where PIPE_BUF is less than 1037, safe_write called by write_to_festival can return with a short write. When this happens, it is very likely that the initial quote character has been written but the final one has not. The next time write_to_festival writes a line, Festival will parse the initial quote character as the final one, and the contents of the line will then be left unquoted and can in principle call arbitrary functions in Festival. Surely this is something that should be prevented. 7.1 Basic command line options http://www.cstr.ed.ac.uk/projects/festival/manual/festival_7.html#SEC19 mentions a "--tts" option that makes Festival just speak its input instead of parsing commands from it. I don't know if this is available in all Festival versions that ELinks needs to support, though. pgpw1AA2lECkZ.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] dangling pointer crash in write_to_festival
Witold Filipczyk <[EMAIL PROTECTED]> writes: > I reset festival.doc_view in really_close_tab. Is it acceptable? I think that is too far from the code that frees the struct document_view. Even if really_close_tab currently were the only way to free a struct document_view, that could change in the future, and the person changing it would probably not remember to add a call to stop_festival. In fact, really_close_tab is already not the only way: if I navigate away from a frameset page, then a struct document_view that festival.c is using can be freed, even though really_close_tab is not called. It seems many places that free struct document_view call detach_formatted first, so you could perhaps call stop_festival From there instead. However, if we're going to assume that detach_formatted is always called before struct document_view is freed, then this should first be carefully checked, and then documented in a comment near the definition of struct document_view. > When a link is followed and the previous document was read out, > the new document is read out from the line number of the > previous document. How to handle this? detach_formatted seems to be called in that situation too, so if it's OK to stop the speech, that should fix it. By the way, the "default" in "Default speech system" is not right, because ELinks does not even try speech systems other than the one selected here. pgpi3BrwSp5Fp.pgp Description: PGP signature ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
Re: [elinks-dev] dangling pointer crash in write_to_festival (was: witekfl branch status)
On Tue, Mar 06, 2007 at 11:33:44PM +0200, Kalle Olavi Niemitalo wrote: > Witold Filipczyk <[EMAIL PROTECTED]> writes: > > > This feature does not collide with screen readers. > > I just want to listen to ELinks sometimes. > > I tried applying the speech commits to master, but it crashes if, > during the speech, I close the tab and thereby cause the struct > document_view to be freed: > > (gdb) backtrace > #0 0x08115569 in write_to_festival (fest=0x81938b8) at > /home/Kalle/src/elinks/src/viewer/text/festival.c:67 > #1 0x08115519 in read_from_festival (fest=0x81938b8) at > /home/Kalle/src/elinks/src/viewer/text/festival.c:45 > #2 0x080ca26b in select_loop (init=0x80c8e23 ) at > /home/Kalle/src/elinks/src/main/select.c:289 > #3 0x080c95af in main (argc=1, argv=0xbffc2444) at > /home/Kalle/src/elinks/src/main/main.c:365 > (gdb) frame > #0 0x08115569 in write_to_festival (fest=0x81938b8) at > /home/Kalle/src/elinks/src/viewer/text/festival.c:67 > 67 if (fest->line >= doc->height) > (gdb) print doc > $3 = (struct document *) 0x8 > (gdb) list > 62 int len; > 63 struct document_view *doc_view = fest->doc_view; > 64 struct document *doc = doc_view->document; > 65 struct screen_char *data; > 66 > 67 if (fest->line >= doc->height) > 68 fest->running = 0; > 69 if (!fest->running) > 70 return; > 71 > > This was with the following commits applied on top of > f2fc4020934621afb9584a468bd87180059ee8c8 (in this order): > > 4e93cbf496c82926f42c0eaf270920f126ace3f8 > 9064e6323b493b5614a9bd02c25729ce2f1650bf > f260691ac4f58e7ce0e282d7b48bddbae8f00828 > c187df9a0adcf0f9821d9b14b1dfcf43139d9bb3 > e965d07055f5dd3e046469232e4b3986fb60cbaf > 60fc3bd04fe3f85c66d1dadbc8ba4f56f576f611 > 91be2ea6b89a7514b75fa31dcba6d9a5ef6c978c > 4d7c491a22c0b9a191df363504f52f8da1c639e1 > 0da23da6b23d25ceb78f0229132d8efb9f3d3781 > > I think, before the speech code is pushed to master, one should > either > > - fix the bug. A new "document-view-delete" event might be a > clean way to do this. I reset festival.doc_view in really_close_tab. Is it acceptable? When a link is followed and the previous document was read out, the new document is read out from the line number of the previous document. How to handle this? Witek ___ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
