| Summary: | x11-wm/windowmaker-0.91.0 buggy code | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | solar (RETIRED) <solar> |
| Component: | Auditing | Assignee: | Luis Medinas (RETIRED) <metalgod> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | lev, spb |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
This is what the start of the second function looks like.
------------------------------------------------------------------------
int WMHandleEvent(XEvent *event)
{
W_EventHandler *hPtr;
W_View *view, *toplevel;
unsigned long mask;
Window window;
WMArrayIterator iter;
if (event->type == MappingNotify) {
XRefreshKeyboardMapping(&event->xmapping);
return True;
}
mask = eventMasks[event->xany.type];
------------------------------------------------------------------------
And it's the "mask = eventMasks[event->xany.type];" that triggers on the debug compiler.
On line 11.. static unsigned long eventMasks[] = { ....
Regarding the first one, there's a clear overflow there, however the ewmh specs do say only the window manager and pager should set this property: http://standards.freedesktop.org/wm-spec/1.3/ar01s03.html#id2522754 If an attacker can change this, it's safe to assume he can set any random property and can do all kinds of craziness such as modifying the clipboard, changing keybindings and modifying resources, so if he's already got to this point...i don't think he would be interested in this :) regarding the second one, I think we have to assume XEvents are trusted input, if an attacker can create his own synthetic events (he's got to a point where he can use XSendEvent(), for example) he can already fake input events to terminals for example, close windows, send click events, anything..so it's already game over :) These should probably still be fixed, but afaict don't look like security issues. Thanks Tavis.. Reassigning bug to gnustep@ as a normal bug report then. we can close this since 0.91.0 isn't on the tree anymore. |
One of our users reported that ssp picked up an overflow in windowmaker in function updateWorkspaceNames() The problem code reads as ------------------------------------------------------------------------ static void updateWorkspaceNames(WScreen *scr) { char buf[1024], *pos; unsigned int i, len, curr_size; pos = buf; len = 0; for(i = 0; i < scr->workspace_count; i++) { curr_size = strlen(scr->workspaces[i]->name); strcpy(pos, scr->workspaces[i]->name); pos += (curr_size+1); len += (curr_size+1); } XChangeProperty(dpy, scr->root_win, net_desktop_names, utf8_string, 8, PropModeReplace, (unsigned char *)buf, len); } ------------------------------------------------------------------------ Upon further investigation after building windowmaker with a debug compiler and -fbounds-checking we can see another function which has problems. wevent.c:216:Bounds error: array reference (93) outside bounds of the array. wevent.c:216: Pointer value: 0x826da64 wevent.c:216: Object `eventMasks': wevent.c:216: Address in memory: 0x826d8f0 .. 0x826d97b wevent.c:216: Size: 140 bytes wevent.c:216: Element size: 4 bytes wevent.c:216: Number of elements: 35 wevent.c:216: Created at: wevent.c, line 11 wevent.c:216: Storage class: static ------------------------------------------------------------------------ I've joined the windowmaker channel on freenode and asked what is the proper method to report bugs to them. But there was no response. I've checked the windowmaker site for a bugzilla but they appear to not have one. http://www.windowmaker.org/bugtracker.html (only plans to put one in place) So I'm filing a bug here which we can use for reference for the upstream wm-devs. It would be ideal if we have somebody who wants to play spot of the BOFs via gdb and these two functions be audited and patched. It is unknown at this time if these two bugs are exploitable in any way. I'm not a windowmaker user so I'm not really planning on doing alot of follow up with this bug. Hopefully our security and gnustep teams can take it from here.