Long buffer (>1537 of ascii 20) sent to xchat client triggers crash. PoC author claims it works for xchat on KDE. Reproducible: Didn't try
Tested, no crash but got a warning: *** XCHAT WARNING: Buffer overflow - shit server! which is from src/common/server.c: default: serv->linebuf[serv->pos] = lbuf[i]; if (serv->pos >= (sizeof (serv->linebuf) - 1)) fprintf (stderr, "*** XCHAT WARNING: Buffer overflow - shit server!\n");
Sorry forgot to mention testing was on RHEL 6 and Fedora 16, same results in KDE and Gnome.
Tested on Gentoo on amd64 with: xorg-server-1.11.2-r1 xmonad-0.9.2 xchat-2.8.8-r2 xchat crashed with: [...] *** XCHAT WARNING: Buffer overflow - shit server! *** XCHAT WARNING: Buffer overflow - shit server! The program 'xchat' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 3597 error_code 11 request_code 53 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Then the program exited. it IS a crash, isn't it? I mean on X system with some fortifying facilities, but still?
However IMO it's hardly a security vuln. xchat doesn't even connect to multiple servers so I can't see how system or user can be affected in any way other than by a regular bug.
Tested on Gentoo on i686 kernel: linux-3.1.4-gentoo xorg-server-1.10.4-r1 xmonad-0.10 xchat-2.8.8-r2 Same result (warnings + crash) Note: xchat module is vulnerable (needs USE="gtk") xchat-text module displays warnings and disconnects from server (no crash).
Backtrace from xchat --sync failing to connect to malicious sever: --snip-- #0 0xb75a35c9 in g_logv (log_domain=0xb7b2497a "Gdk", log_level=G_LOG_LEVEL_ERROR, format=0xb7b24bd6 "%s", args1=0xbfffe31c "") at gmessages.c:553 #1 0xb75a366a in g_log (log_domain=0xb7b2497a "Gdk", log_level=G_LOG_LEVEL_ERROR, format=0xb7b24bd6 "%s") at gmessages.c:577 #2 0xb7ae6fe2 in gdk_x_error (display=0x80f4e00, error=0xbfffe3ec) at gdkmain-x11.c:486 #3 0xb786a279 in _XError (dpy=0x80f4e00, rep=0x81b5818) at /var/tmp/portage/x11-libs/libX11-1.4.4/work/libX11-1.4.4/src/XlibInt.c:1583 #4 0xb7866544 in handle_error (dpy=0x80f4e00, err=0x81b5818, in_XReply=1) at /var/tmp/portage/x11-libs/libX11-1.4.4/work/libX11-1.4.4/src/xcb_io.c:212 #5 0xb78669bc in handle_response (dpy=0x80f4e00, response=0x81b5818, in_XReply=1) at /var/tmp/portage/x11-libs/libX11-1.4.4/work/libX11-1.4.4/src/xcb_io. #6 0xb78674fd in _XReply (dpy=0x80f4e00, rep=0xbfffe55c, extra=0, discard=1) at /var/tmp/portage/x11-libs/libX11-1.4.4/work/libX11-1.4.4/src/xcb_io.c:626 #7 0xb7861b58 in XSync (dpy=0x80f4e00, discard=0) at /var/tmp/portage/x11-libs/libX11-1.4.4/work/libX11-1.4.4/src/Sync.c:44 #8 0xb7861bf9 in _XSyncFunction (dpy=0x0) at /var/tmp/portage/x11-libs/libX11-1.4.4/work/libX11-1.4.4/src/Synchro.c:35 #9 0xb786821d in _XPrivSyncFunction (dpy=0x80f4e00) at /var/tmp/portage/x11-libs/libX11-1.4.4/work/libX11-1.4.4/src/XlibInt.c:251 #10 0xb7840aed in XCreatePixmap (dpy=0x80f4e00, d=23069176, width=32773, height=14, depth=24) at /var/tmp/portage/x11-libs/libX11-1.4.4/work/libX11-1.4.4/ #11 0xb7ae7ce8 in _gdk_pixmap_new (drawable=0x81b48b0, width=32773, height=14, depth=24) at gdkpixmap-x11.c:175 #12 0xb7a9d0c4 in IA__gdk_pixmap_new (drawable=0x81b48b0, width=32773, height=14, depth=24) at gdkpixmap.c:249 #13 0x080892b3 in gtk_xtext_render_flush (xtext=0x81ca000, x=21, y=67, str=0x830ea62 "hybrid7.debian.local ", '\024' <repeats 179 times>..., len=2047, gc #14 0x0808a727 in gtk_xtext_render_str (xtext=0x81ca000, y=67, ent=0x830ea30, str=0x830ea5c "\003\062\062*\017 hybrid7.debian.local ", '\024' <repeats 17 #15 0x0808c54c in gtk_xtext_render_line (xtext=0x81ca000, ent=0x830ea30, line=4, lines_max=23, subline=0, win_width=509) at xtext.c:4161 #16 0x0808d684 in gtk_xtext_render_page (xtext=0x81ca000) at xtext.c:4715 #17 0x080866f8 in gtk_xtext_paint (widget=0x81ca000, area=0xbfffedc4) at xtext.c:1412 #18 0x0808698b in gtk_xtext_expose (widget=0x81ca000, event=0xbfffedb8) at xtext.c:1469 #19 0xb7ca461b in _gtk_marshal_BOOLEAN__BOXED (closure=0x811e488, return_value=0xbfffeac0, n_param_values=2, param_values=0x8196428, invocation_hint=0xbf #20 0xb7971c74 in g_type_class_meta_marshal (closure=0x811e488, return_value=0xbfffeac0, n_param_values=2, param_values=0x8196428, invocation_hint=0xbfff #21 0xb797195e in g_closure_invoke (closure=0x811e488, return_value=0xbfffeac0, n_param_values=2, param_values=0x8196428, invocation_hint=0xbfffeadc) at g #22 0xb798a6cf in signal_emit_unlocked_R (node=0x811e650, detail=0, instance=0x81ca000, emission_return=0xbfffebfc, instance_and_params=0x8196428) at gsig #23 0xb79898e1 in g_signal_emit_valist (instance=0x81ca000, signal_id=41, detail=0, var_args=0xbfffecd0 "\350\354\377\277\070\236\021\b\001") at gsignal.c #24 0xb7989b41 in g_signal_emit (instance=0x81ca000, signal_id=41, detail=0) at gsignal.c:3040 #25 0xb7e2e1a5 in gtk_widget_event_internal (widget=0x81ca000, event=0xbfffedb8) at gtkwidget.c:4984 #26 0xb7e2de04 in IA__gtk_widget_send_expose (widget=0x81ca000, event=0xbfffedb8) at gtkwidget.c:4813 #27 0xb7ca134d in IA__gtk_main_do_event (event=0xbfffedb8) at gtkmain.c:1620 #28 0xb7ab390b in _gdk_window_process_updates_recurse (window=0x81b48b0, expose_region=0x816e480) at gdkwindow.c:5429 #29 0xb7ab3819 in _gdk_window_process_updates_recurse (window=0x81b45d0, expose_region=0x81f3f20) at gdkwindow.c:5402 #30 0xb7afd8a4 in _gdk_windowing_window_process_updates_recurse (window=0x81b45d0, region=0x81f3f20) at gdkwindow-x11.c:5619 #31 0xb7ab3bbe in gdk_window_process_updates_internal (window=0x81b45d0) at gdkwindow.c:5588 #32 0xb7ab3dd4 in IA__gdk_window_process_all_updates () at gdkwindow.c:5696 #33 0xb7bf0424 in gtk_container_idle_sizer (data=0x0) at gtkcontainer.c:1360 #34 0xb7a86451 in gdk_threads_dispatch (data=0x81f3a50) at gdk.c:512 #35 0xb759cd0d in g_idle_dispatch (source=0x81f8748, callback=0xb7a863fb <gdk_threads_dispatch>, user_data=0x81f3a50) at gmain.c:4558 #36 0xb75990f2 in g_main_dispatch (context=0x810bf40) at gmain.c:2441 #37 0xb759a45a in g_main_context_dispatch (context=0x810bf40) at gmain.c:3014 #38 0xb759a8b4 in g_main_context_iterate (context=0x810bf40, block=1, dispatch=1, self=0x80e55a8) at gmain.c:3092 #39 0xb759b026 in g_main_loop_run (loop=0x81b3ff0) at gmain.c:3300 #40 0xb7ca0b11 in IA__gtk_main () at gtkmain.c:1256 #41 0x08061903 in fe_main () at fe-gtk.c:290 #42 0x080b5713 in main (argc=2, argv=0xbffff234) at xchat.c:920 --snip-- After receiving data from server, if it's too long, the warning is printed to stderr: "*** XCHAT WARNING: Buffer overflow - shit server!\n" Then, xchat is trying to display server's answer with some kind of GTK widget and tries to allocate large pixmap: IA__gdk_pixmap_new (drawable=0x81b48b0, width=32773, height=14, depth=24) and X error BadAlloc is being generated. These two reactions (stderr warnings and GTK display fail) are not related. You can trigger xchat crash without stderr warnings by modyfing the PoC (from $url): - buffer += "A"*4000 # anything can go here and it still works. + buffer += "A"*486 # anything can go here and it still works.
CVE-2011-5129 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-5129): Heap-based buffer overflow in XChat 2.8.9 and earlier allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a long response string.
This package has been removed. (Maintainers, please inform us next time you do this with a security bug open in [upstream] or [ebuild] status.) GLSA vote: no.
GLSA Vote: No No GLSA - Closing
