pine.420.txt

`-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
I reported the vulnerability below to the Pine team on Oct 21, when 4.20  
was current. 4.21 (which I just noticed on freshmeat) seems to fix the  
problem even though it's not mentioned in the release notes. Since it's  
not, I thought some disclosure was in order. I built 4.21 in the same way  
I built 4.20 (below).  
  
  
Best,  
Jim Hebert <[email protected]>  
  
- ---------- Forwarded message ----------  
Date: Thu, 21 Oct 1999 03:40:27 -0400 (EDT)  
From: Jim Hebert <[email protected]>  
To: [email protected]  
Subject: Security: expanding env vars in URLs  
  
1 line summary: environment vars are expanded in URLs I try to view  
  
Versions tested: 4.10 and 4.20. 4.10 from "Red Hat" rpm and 4.20 built  
from pristine sources to slx build target. Both seem equally affected.  
  
Discussion:  
  
A certain mailing I get occasionally recently had a url like  
  
http://something/some/cgi$12345  
  
I noticed viewing the url didn't seem to work right, and finally figured  
out that the url must get near enough to a shell to allow environment  
variable expansion.  
  
A quick test for me was:  
echo 'setenv WWW www.securityfocus.com' >> .tcshrc  
source .tcshrc  
pine  
(view a link I mailed myself like: http://$WWW )  
it works, I visit securityfocus  
  
Doesn't sound dangerous/exploitable yet, right? Well, imagine your shell  
is bash, someone sends you a html formatted mail, and the url is long:  
  
"Click here for cool stuff!"  
the url is very long, long enough that the dangerous part is elided when  
pine asks the user to confirm they want to visit that page  
the url ends with something like:  
?trojan=$(shell command)  
  
The user says "yeah, sure, visit that page" since they don't see the  
dangerous part.  
  
At the least least, people put your environment variables into their  
webserver access logs. At most, people can get you to run shell commands  
(bad enough by itself) _and_ have the output of them sent to them if they  
wish.  
  
I searched the bugtraq archives and didn't see anything about this. Sorry  
if it's a known issue.  
  
Thanks,  
jim  
  
[email protected]  
  
  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1.0.0 (GNU/Linux)  
Comment: For info see http://www.gnupg.org  
  
iD8DBQE4Mzj9B1oRfeAiKDARAs7ZAJ9WpvdZ8aVLAl1N89dXl1mun1jFLQCeP8lq  
2F6L+3uiYG63eOpgVv0ME5I=  
=Zj4l  
-----END PGP SIGNATURE-----  
  
  
Reply-To: Pavel Kankovsky <[email protected]>  
  
  
An attempt was made to fix the vulnerability. An unsuccessful one.  
  
The following line in pine/mailview.c controls whether the quoting is done  
or not:  
  
if(strpbrk(handle->h.url.path, "&*;<>?[|~$") != NULL){ /* specials? */  
  
It is obvious something is wrong: they try to explicitly list all harmful  
characters and we all know this is the "disaster pattern". It is left as  
an exercise for the reader for find at least two characters not included  
in the list that have special meaning for the shell. Special bonus for  
finding a character that is not on the list and has the power to defeat  
the effect of quoting (and I am not speaking about bash 1.x \377 bug,  
btw. it chokes on ``echo "$(echo '1`2')"'' as well...another good reason  
to get rid of it). If you need a hint, search the same function for the  
following line:  
  
sstrcpy(&cmdp, handle->h.url.path);  
  
Yes, I know, providing patches or pointing out the mistakes clearly might  
be more efficient but I hope Pine developers will get sick of their own  
code having no choice but to analyze it and will rewrite it from the  
scratch...and cleanly (for instance, they should use a single (reasonably  
safe) substitution procedure for mailcap and urls).  
  
  
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]  
"Resistance is futile. Open your source code and prepare for assimilation."  
  
  
`