The following advisory from securesoftware@list.cr.yp.to for asp2php 0.76.23, but I was able to get dev-php/asp2php-0.76.19 to SegFault using the given exploits, so it's probably vulnerable. Date: 15 Dec 2004 08:21:54 -0000 From: "D. J. Bernstein" <djb@cr.yp.to> Subject: [remote] [control] asp2php 0.76.23 preparse() overflows token buffer; +preparse() overflows temp buffer To: securesoftware@list.cr.yp.to, mike@mikekohn.net X-HELOcheck: OK: FQDN Mailing-List: contact securesoftware-help@list.cr.yp.to; run by ezmlm Mail-Followup-To: securesoftware@list.cr.yp.to, mike@mikekohn.net Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. [-- Attachment #1 [details] --] [-- Type: text/plain, Encoding: 7bit, Size: 1.6K --] Qiao Zhang, a student in my Fall 2004 UNIX Security Holes course, has discovered two remotely exploitable security holes in asp2php. I'm publishing this notice, but all the discovery credits should be assigned to Zhang. You are at risk if you take an ASP script from an email message (or a web page or any other source that could be controlled by an attacker) and feed that script through asp2php. (The asp2php documentation does not tell users to avoid taking input from the network.) Whoever provides that script then has complete control over your account: she can read and modify your files, watch the programs you're running, etc. Proof of concept: On an x86 computer running FreeBSD 4.10, type wget http://downloads.mikekohn.net/asp2php/asp2php-0.76.23.tar.gz gunzip < asp2php-0.76.23.tar.gz | tar -xf - cd asp2php-0.76.23 make to download and compile the asp2php program, version 0.76.23 (current). Then save the file 29-1.asp attached to this message, and type ./asp2php 29-1.asp with the unauthorized result that a file named EXPLOITED is created in the current directory. 29-2.asp is similar but uses a separate buffer overflow. (I tested these with a 541-byte environment, as reported by printenv | wc -c.) Both buffer overflows can be blamed on gettoken(), which has a fundamentally broken gets()-style API. The preparse() function calls gettoken() to read data into a 1024-byte token[] array, and to read data into a 1024-byte temp[] array. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
Created attachment 46173 [details] File 29-1.asp from advisory
Created attachment 46174 [details] File 29-2.asp from advisory
php herd, please verify/advise.
asp2php (both 0.76.23 and 0.76.19) segfault for me, but it does NOT create the 'EXPLOITED' file as described here.
That's expected, since the exploit is tuned for FreeBSD 4.10... Upstream isn't completely dead so we can still hope they will release a fix for it. Anyway, exploitation path for this is very unlikely and requires serious social engineering, so I think we can wait a little.
====================================================== Candidate: CAN-2004-1261 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1261 Reference: MISC:http://tigger.uic.edu/~jlongs2/holes/asp2php.txt Multiple buffer overflows in the preparse function in asp2php 0.76.23 allow remote attackers to execute arbitrary code via crafted ASP scripts. ======================================================
Sent email upstream to get release status.
Upstream acks but won't fix it. "This report is the most idiotic thing i've ever heard of in my life... asp2php is a command line program, not a networked program. if asp2php can be used to delete files or get root access to a system, then the kernel itself has security holes, not asp2php..." I think we should mask it prior to removal.
PHP team please comment.
Okay. It doesn't look that hard to patch, but I'm not happy with Gentoo carrying packages where there's no support from UPSTREAM on security bugs. DJB's tone (as per usual) probably didn't help there :-) I'm masking the package, and sending an email upstream. If I don't hear back from upstream by the end of January, we'll drop this package. Best regards, Stu
Package has been masked
(now back from my vacation) I would agree with the author that the user that runs asp2php on untrusted input deserves everything they get. However I do believe that it should still be fixed.
Any ETA on a fix for this or should we drop the package?
UPSTREAM has no intention of fixing the package. I'm in favour of dropping it. Best regards, Stu
What's the specific policy regarding masking versus removing? I'd be in favor of masking with a memo about why--after all, so long as a user knows about the vulnerability, it's essentially not a vulnerability (while I'm not as angry as the upstream maintainer, this *is* a fairly minor issue). The vuln treatment policy doesn't say that there's anything wrong with doing this.
The (unwritten) policy is that a security-masked package should be removed after 60 days if upstream situation did not evolve... and maintainer agrees. If you think we should change this policy (and keep security-masked packages in the tree) please submit a new bug, for example in "GLSA Errors" component, so that we can further discuss this, as this is more far-reaching than the asp2php specific case.
ebuild has been masked 30 dec 2004, so it should be read for removal by now
dev-php/asp2php has been removed from the tree.
that's a new upstream version..can you readd this package to tree?
According to their Changelog, the issue is not fixed. When it will be fixed (or when you can prove it has been fixed) you should open a new bug and ask for it to be included in Portage like a new package.
