Buffer overflow in URI processing in HTTrack and WinHTTrack before 3.42-3
allows remote attackers to cause a denial of service (crash) and possibly
execute arbitrary code via a long URL.
Feel free to bump it if I don't get it first.
Bumped in cvs.
Arches, please test and mark stable:
Target keywords : "amd64 ppc sparc x86"
Note @security: if i understand well, it's a "command-line" buffer overflow vulnerability, i.e. a bof triggered by a long URL as a parameter of the command-line, thus not remotely triggerable. Thus there is no security impact since the user voluntarily enters a clearly erroneous URI.
What about an external program/script which spawns httrack in the background? It might take a user-supplied URL and pass it to httrack (which is probably a valid use case)...
(In reply to comment #7)
> What about an external program/script which spawns httrack in the background?
> It might take a user-supplied URL and pass it to httrack (which is probably a
> valid use case)...
In that case too, the user would himself supply a strange URL to his script, it's not a remotely exploitable overflow. If the user trusts something like "http://foo.bar/AAAAAAAAAAAAAAA%33%44%55%whatever", i suspect he would also trust any kind of URL, even containg ';' or back-quotes ``, and he can be fooled with any sort of shell injection code.
There used to be a lot of command-line buffer overflows (or format-string vulns) and we usually don't handle this as a security issue.
See http://bugs.gentoo.org/show_bug.cgi?id=91737#c2 and http://bugs.gentoo.org/show_bug.cgi?id=91737#c21 for example
Any other inputs?
As far as automated systems go, they might properly pass the URL to the program (see python's spawn* methods), so no metacharacter issue there. On the other hand I follow your logic of very little exploitation vector. Since I don't want to leave this ebuild with inconsistent stable versions, let's leave it open for PPC to stable, rerate it C3 and agree on a NO / close INVALID.
I vote NO for a GLSA.