using dillo, visit the URL above, then look at the statusbar message. If you see a message like "Not Found: fa854ef32fa342" or similar, dillo interpreted the format string specifiers I sent it in the specially crafted html file. This could likely be used to execute arbritrary code simply by visiting an attackers website, or viewing an html email (some mua's use dillo for html rendering, i use with muttt when no plain text part is sent!).
btw, the responsible code is at interface.c:1061 here's some backtrace Breakpoint 1, a_Interface_msg (bw=0x80f4118, format=0x81c8570 "File Not Found: /%x%x%x") at interface.c:1061 (gdb) bt #0 a_Interface_msg (bw=0x80f4118, format=0x81c8570 "File Not Found: /%x%x%x") at interface.c:1061 #1 0x0805b7f1 in a_Capi_ccc (Op=2, Branch=2, Dir=1, Info=0x81cbc40, Data1=0x81c7df8, Data2=0x81c84b0) at capi.c:500 #2 0x0805bd2d in a_Chain_fcb (Op=2, Info=0x81cbd10, Data1=0x81c7df8, Data2=0x81c84b0) at chain.c:89 #3 0x080ac14e in Dpi_parse_token (conn=0x81cbc60) at dpi.c:263 #4 0x080ac35f in Dpi_process_io (Op=0, Data1=0x81cbd30, conn=0x81cbc60) at dpi.c:317 #5 0x080ad1e5 in a_Dpi_ccc (Op=2, Branch=3, Dir=1, Info=0x81cbd10, Data1=0x81cbd30, Data2=0x0) at dpi.c:703 #6 0x0805bd2d in a_Chain_fcb (Op=2, Info=0x81cbc00, Data1=0x81cbd30, Data2=0x0) at chain.c:89 #7 0x080ae696 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x81cbc00, Data1=0x81cbd30, Data2=0x0) at IO.c:691 #8 0x080adfc2 in IO_read (io=0x81cbd30) at IO.c:466 #9 0x080ae249 in IO_callback (src=0x81cbc28, cond=17, data=0x5) at IO.c:556 #10 0x4039c474 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0
Tavis: I assume you find it, so I will temporarily set Component to Auditing so that the Audit team can verify it. Looks like a classic format string thing to me, but I didn't look at the code.
Okay, here are some of the details for whoever checks it out: vulnerable code: 1051 /* 1052 * Set the status string on the bottom of the dillo window. 1053 */ 1054 void a_Interface_msg(BrowserWindow *bw, const char *format, ... ) 1055 { 1056 static char msg[1024]; 1057 va_list argp; 1058 1059 if ( bw ) { 1060 va_start(argp, format); 1061 vsnprintf(msg, 1024, format, argp); 1062 va_end(argp); 1063 a_I18n_gtk_label_set_text(GTK_LABEL(bw->status), msg); 1064 bw->status_is_link = 0; 1065 } 1066 } Nothing wrong with this, but look at how it's called in capi.c: 498 } else if (strcmp(Data2, "send_status_message") == 0) { 499 gchar *Data1_enc = a_I18n_locale_to_DILLO_CHARSET(Data1); 500 a_Interface_msg(conn->dd->bw, Data1_enc); 501 g_free(Data1_enc); 502 } else if (strcmp(Data2, "chat") == 0) { where Data1_enc is unfiltered and can be controlled via the html, I've attached a patch that fixes this issue. I think this is a fairly textbook error, shouldnt cause any problems to an attacker.
Created attachment 47645 [details, diff] fix format string bug actually, i can see there's another one in there as well, so I fixed that one as well :)
This looks rather clear to me. Switching to vulnerability.
upstream informed (security@ cc'ed).
upstream maintainer has replied via email, the issue is now fixed in CVS and plans to make a release candidate later today for a planned full release before Jan 15th.
This is CAN-2005-0012, public since it leaked from the Dillo Changelogs. usata: please bump to 0.8.3-r4 with patch, or to 0.8.4_rc1 if it's out (your choice).
Tavis: usata is not available now, I think he won't matter if you commit the patch and/or the rc1 version on his behalf.
Okay, I'll bounce some of the info to usata and he can decide about -rc1, it's such a simple patch for 0.8.3 I don't expect any issues with it.
www-client/dillo-0.8.3-r4 contains the patch, already stable on x86.
sparc ppc alpha amd64 arm: please test and mark stable
amd64 stable
ppc stable
Stable on alpha.
Stable on sparc.
Draft ready, security please review
GLSA 200501-11 arm, please mark stable to benefit from GLSA
Thanks taviso and koon. I didn't have time to look at it. I'll add dillo-0.8.4.ebuild to CVS asap.
