Bug 233563 (CVE-2008-3429) – www-client/httrack <3.42.3 URI processing buffer overflow (CVE-2008-3429)

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Robert Buchholz (RETIRED) 2008-08-01 08:59:51 UTC]

CVE-2008-3429 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3429):
  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.

[Comment 1 Marcelo Goes (RETIRED) 2008-08-01 18:13:11 UTC]

Feel free to bump it if I don't get it first.
- Marcelo

[Comment 2 Marcelo Goes (RETIRED) 2008-08-03 21:29:08 UTC]

Bumped in cvs.

[Comment 3 Robert Buchholz (RETIRED) 2008-08-03 21:43:12 UTC]

Arches, please test and mark stable:
=www-client/httrack-3.42.3
Target keywords : "amd64 ppc sparc x86"

[Comment 4 Raúl Porcel (RETIRED) 2008-08-04 16:50:08 UTC]

sparc/x86 stable

[Comment 5 Tobias Heinlein (RETIRED) 2008-08-04 17:10:50 UTC]

amd64 stable

[Comment 6 Raphael Marichez (Falco) (RETIRED) 2008-08-06 16:56:54 UTC]

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.

[Comment 7 Christian Hoffmann (RETIRED) 2008-08-06 17:45:41 UTC]

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)...

[Comment 8 Raphael Marichez (Falco) (RETIRED) 2008-08-07 07:52:33 UTC]

(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?

[Comment 9 Robert Buchholz (RETIRED) 2008-08-07 21:06:28 UTC]

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.

[Comment 10 Tobias Scherbaum (RETIRED) 2008-08-08 20:21:58 UTC]

ppc stable

[Comment 11 Robert Buchholz (RETIRED) 2008-08-15 14:29:20 UTC]

I vote NO for a GLSA.