Copy&paste from http://www.zone-h.org/en/advisories/read/id=8480/ ZRCSA-200503 - ktools Buffer Overflow Vulnerability 11/27/2005 Zone-H Research Center Security Advisory 200503 http://www.zone-h.fr Date of release: 27/11/2005 Software: ktools (http://konst.org.ua/ktools) Affected versions: <= 0.3 Risk: Medium Discovered by: Mehdi Oudad "deepfear" and Kevin Fernandez "Siegfried" from the Zone-H Research Team Background (from http://konst.org.ua/ktools) ---------- ktools is a library which I wrote for my own programming needs, though its main purpose is to provide various text-mode user interface controls without a need to write too much code. Details -------- There is a buffer overflow in kkstrtext.h : #define VGETSTRING(c, fmt) { va_list vgs__ap; char vgs__buf[1024]; va_start(vgs__ap, fmt); vsprintf(vgs__buf, fmt, vgs__ap); c = vgs__buf; va_end(vgs__ap); } This library is used in the following softwares: centericq orpheus motor groan (see http://konst.org.ua/en/konstware) It can be exploited for example in centericq when editing a contact's details with a detail field longer than 1024 chars (a <description> field of a rss feed for example). Details: - centericq.cc : case ACT_EDITUSER: c->save(); /***************** here************/ if(face.updatedetails(c, c->getdesc().pname)) { if(c->getdesc().pname == infocard) c->setdispnick(c->getnick()); ... ... - icqdialogs.cc : bool icqface::updatedetails(icqcontact *c, protocolname upname) { ... ... while(!finished) {; gendetails(db.gettree(), c); ... ... gendetails() .. if((capab.count(hookcapab::flexiblereg) && ri.params.empty()) || !capab.count(hookcapab::flexiblereg)) { i = tree->addnode(_(" About ")); tree->addleaff(i, 0, 39, " %s ", about.c_str()); - treeview.cc : int treeview::addleaff(int parent, int color, int ref, const char *fmt, ...) { string buf; VGETSTRING(buf, fmt); return addleaf(parent, color, (void *) ref, buf); } - kkstrtext.h : #define VGETSTRING(c, fmt) { va_list vgs__ap; char vgs__buf[1024]; va_start(vgs__ap, fmt); vsprintf(vgs__buf, fmt, vgs__ap); c = vgs__buf; va_end(vgs__ap); } Solution --------- None. Vendor contacted on 18/11 and 25/11, no answer. http://www.zone-h.org/en/advisories/read/id=8480/ (Some rights reserved, http://creativecommons.org/licenses/by-nc-nd/2.0/) I haven't seen groan in portage, but the other 3 programs are. Reproducible: Always Steps to Reproduce:
Exploitability path doesn't seem obvious to me. There is a buffer overflow but it doesn't mean it is under the control of a remote attacker... Looks rather convoluted with centericq, and even more unlikely with orpheus (command-line MP3 player) and motor (text-mode programming env). Setting to Auditing for a review.
tigger says : centericq could be exploited through the already-explained exploit path. For orpheus maybe its ID3 tag modification possibilities could be exploited. For motor, no clue. Keeping this bug in Auditing as a tracker, waiting for more auditing verifications for orpheus and motor. Creating a separate bug (in Vulnerabilities) for centericq.
(In reply to comment #2) > tigger says : centericq could be exploited through the already-explained > exploit > path. For orpheus maybe its ID3 tag modification possibilities could be > exploited. For motor, no clue. > > Keeping this bug in Auditing as a tracker, waiting for more auditing > verifications for orpheus and motor. > > Creating a separate bug (in Vulnerabilities) for centericq. > for orpheus it is just the path of the songs, i don't think it's exploitable, i have no idea for motor. But you should patch the overflow in a new version just in case..
What's up here? Perhaps just close this?
We're patching motor - see /usr/portage/dev-util/motor/files/motor-3.2.2-security.patch , so that's taken care of. I investigated orpheus this morning and agree with Koon: exploiting orpheus is either very difficult or impossible. In order for an attacker to hit the buffer he'd have to supply more than 1024 bytes somehow in the ID3 tags, the Ogg Vorbis comments, or some other such method. Every entry point I looked at was a fixed-length read from a file based on the ID3 spec or the Ogg Vorbis spec, so your chances of getting anything big enough through to the VGETSTRING macro are pretty slim. I was able to crash the application by entering a >1024 byte string in the ID3 tag modification menu, but that's user input from a console - not dangerous. I think we should apply the same one-line patch that liquidx applied to motor and close this bug. I can't do this as I don't have commit rights. :\
Adding maintainer. Patching orpheus won't hurt.
Sound, please patch orpheus so we can finally get rid of this almost 2 years old bug :/
(In reply to comment #7) > Sound, please patch orpheus so we can finally get rid of this almost 2 years > old bug :/ > +*orpheus-1.6-r1 (06 Nov 2007) + + 06 Nov 2007; Samuli Suominen <drac@gentoo.org> + +files/101_fix-buffer-overflow.diff, +orpheus-1.6-r1.ebuild: + Fix security bug 113683, CVE-2005-3863, a stack-based buffer overflow in + kkstrtext.h in ktools library and stabilize amd64.
Thanks drac. Arches, please test and mark stable media-sound/orpheus-1.6-r1. target keywords "alpha amd64 ~ppc sparc x86" (dev-util/motor is already stable)
x86 stable
alpha/sparc stable, thanks Tobias and Alex
glsa request filed.
finally, after a quick talk with rbu, and given that exploitation is extremely unlikely as explained in previous comment, we took the decision to discard the glsa request and close without glsa. feel free to reopen if you disagree.
