You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rob Hartill <ro...@imdb.com> on 1996/06/28 05:29:09 UTC
WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
I can't work out what he's saying, but my guess is that the imap
module is intercepting a URL such as foo.map.html.
not acked
-=-=
Message-Id: <19...@taz.hyperreal.com>
From: rodmur@ecst.csuchico.edu
To: apache-bugs%apache.org@organic.com
Date: Thu Jun 27 20:16:07 1996
Subject: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX
Submitter: rodmur@ecst.csuchico.edu
Operating system: HPUX, version:
Version of Apache Used: 1.1b4
Extra Modules used: mod_imap, lots
URL exhibiting problem: http://www.ecst.csuchico.edu/~rodmur/test.html
Symptoms:
--
If you have a file referenced in a <code>
<a href=" "> </a> </code> then Apache tries
to give you a menu, even if the .map isn't at
the end of the file.
<code>
<a href="blah.map.html">
</code>
will try to give you a menu of the current
working directory, but it doesn't really do it,
it does stuff much wierder, I don't think I
can describe it. Check out:
http://www.ecst.csuchico.edu/~rodmur/test.html
it will give an example.
Also:
<code>
<img ismap src="blah.map.gif">
</code>
Causes a Segemetation Violation, and the that
daemon core dumps. Unfortunately I can't
find the core file.
Dale
--
Backtrace:
--
--
----- End of forwarded message from rodmur@ecst.csuchico.edu -----
--
Rob Hartill (robh@imdb.com)
The Internet Movie Database (IMDb) http://www.imdb.com/
...more movie info than you can poke a stick at.
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Michael Douglass <mi...@texas.net>.
On Fri, 28 Jun 1996, Brian Behlendorf wrote:
>
> While I think in this situation it might be better to make sure that the
> included file can actually be included (i.e., text/*,
> application/x-httpd-cgi or whatever) I think a fix like the below would be
> appropriate as well. We should at least try and prevent cores no matter
> what garbage the server is pointed at.
>
I'll take a look at it tonight and do some testing to see which method
would be best. Want to keep in mind performance of the server as well as
using up lots of RAM. Although I think that a single test for the size of
the first field being < 100 (SMALLBUF) should be adaquate since it's just
as likely to be caught on the first field of the line than anywhere else.
Michael Douglass
Texas Networking, Inc.
"To be a saint is to be an exception; to be a true man is the rule.
Err, fail, sin if you must, but be upright. To sin as little as
possible is the law for men; to sin not at all is a dream for angels."
- Victor Hugo, "Les Miserables"
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Alexei Kosut <ak...@organic.com>.
On Fri, 28 Jun 1996, Brian Behlendorf wrote:
> > I still don't see what you're getting at. The problem here is that
> > mod_imap core dumps when it gets fed binary data (like a GIF). How do you
> > prevent this from happening by looking at the data type when all you know
> > is that the filename is "foo.map"?
> >
> > I'm confused.
>
> I guess I meant catch it before even farming it off to mod_imap (though I
> agreed, mod_imap should be fixed to not core dump no matter what is thrown
> at it). I.e., the server says to itself "okay, I'm supposed to include
> file.map. Oops, I can't do that, because file.map isn't text or a CGI
> script". If the list of "acceptible" included content isn't difficult to
> come up with, then that seems like a proper path to go down....
Huh? As near as I can tell, this has nothing to do with includes.
At least, the user's original message had nothing to do with them.
Besides, I believe mod_include already only includes text types.
(Remember, though, that, in 1.1, an imagemap file *is* a text/html file if
no coordinates are present).
-- Alexei Kosut <ak...@organic.com> The Apache HTTP Server
http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Brian Behlendorf <br...@organic.com>.
On Fri, 28 Jun 1996, Alexei Kosut wrote:
> On Fri, 28 Jun 1996, Brian Behlendorf wrote:
>
> > The metainformation comes from the server configs, after all, that's
> > what's telling the server to process it as a map and not just a straight
> > text file.
>
> I still don't see what you're getting at. The problem here is that
> mod_imap core dumps when it gets fed binary data (like a GIF). How do you
> prevent this from happening by looking at the data type when all you know
> is that the filename is "foo.map"?
>
> I'm confused.
I guess I meant catch it before even farming it off to mod_imap (though I
agreed, mod_imap should be fixed to not core dump no matter what is thrown
at it). I.e., the server says to itself "okay, I'm supposed to include
file.map. Oops, I can't do that, because file.map isn't text or a CGI
script". If the list of "acceptible" included content isn't difficult to
come up with, then that seems like a proper path to go down....
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Alexei Kosut <ak...@organic.com>.
On Fri, 28 Jun 1996, Brian Behlendorf wrote:
> The metainformation comes from the server configs, after all, that's
> what's telling the server to process it as a map and not just a straight
> text file.
I still don't see what you're getting at. The problem here is that
mod_imap core dumps when it gets fed binary data (like a GIF). How do you
prevent this from happening by looking at the data type when all you know
is that the filename is "foo.map"?
I'm confused.
-- Alexei Kosut <ak...@organic.com> The Apache HTTP Server
http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Brian Behlendorf <br...@organic.com>.
On Fri, 28 Jun 1996, Alexei Kosut wrote:
> On Fri, 28 Jun 1996, Brian Behlendorf wrote:
>
> > While I think in this situation it might be better to make sure that the
> > included file can actually be included (i.e., text/*,
> > application/x-httpd-cgi or whatever) I think a fix like the below would be
>
> How would you tell? Unix (well, most of 'em) doesn't
> carry metainformation on a file's data type other than what can be gleamed
> by its filename. If you have a file called "foo.map" (ignore this guy's
> mail for a minute"), there's no way to tell that it actually has a GIF
> image stored inside, other than looking at the file.
The metainformation comes from the server configs, after all, that's
what's telling the server to process it as a map and not just a straight
text file.
I won't get into "magic numbers".
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Alexei Kosut <ak...@organic.com>.
On Fri, 28 Jun 1996, Brian Behlendorf wrote:
> While I think in this situation it might be better to make sure that the
> included file can actually be included (i.e., text/*,
> application/x-httpd-cgi or whatever) I think a fix like the below would be
How would you tell? Unix (well, most of 'em) doesn't
carry metainformation on a file's data type other than what can be gleamed
by its filename. If you have a file called "foo.map" (ignore this guy's
mail for a minute"), there's no way to tell that it actually has a GIF
image stored inside, other than looking at the file.
> appropriate as well. We should at least try and prevent cores no matter
> what garbage the server is pointed at.
Nah, I think it's a feature. ;)
-- Alexei Kosut <ak...@organic.com> The Apache HTTP Server
http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Brian Behlendorf <br...@organic.com>.
While I think in this situation it might be better to make sure that the
included file can actually be included (i.e., text/*,
application/x-httpd-cgi or whatever) I think a fix like the below would be
appropriate as well. We should at least try and prevent cores no matter
what garbage the server is pointed at.
Brian
On Fri, 28 Jun 1996, Michael Douglass wrote:
> On Fri, 28 Jun 1996, Michael Douglass wrote:
>
> > On Fri, 28 Jun 1996, Alexei Kosut wrote:
> >
> >>> <code>
> >>> <img ismap src="blah.map.gif">
> >>> </code>
> >>>
> >>> Causes a Segemetation Violation, and the that
> >>> daemon core dumps. Unfortunately I can't
> >>> find the core file.
> >>
> >> This is no doubt due to the fact that you, again, are having the file
> >> parsed by the imagemap handler, and it is not expecting a GIF, but a text
> >> file with imagemap rules.
>
> Hopefully I'm not too far off field here, but it is definitely the case
> and the problem seems very likely to be a buffer overflow. Of course, this
> is just at first glance; but I can see how a binary file in the following
> code (where a text file is expected) can cause problems. Hrm.. Seems
> to me that this would be the problem with that:
>
> *** snip ***
> char input[LARGEBUF] = {'\0'};
> char directive[SMALLBUF] = {'\0'};
> *** snip ***
> if (sscanf(input, "%s %s", directive, value) != 2) {
> continue; /* make sure we read two fields */
> }
> *** snip ***
>
> I can think of two easy ways to make sure that the server doesn't core
> because of it. One, make directive and value both LARGEBUF so that they
> are never overflowed; or two calculate the sizes of the two items before
> doing the sscanf and making sure that they will fit in a SMALLBUF.
>
> ie.
>
> endpoint = strchr( input, ' ' );
> if ( endpoint - input > SMALLBUF ) {
> RETURN ERROR STATEMENT ABOUT MAP FILE BEING INVALID AND EXIT
> }
>
> Michael Douglass
> Texas Networking, Inc.
>
> "To be a saint is to be an exception; to be a true man is the rule.
> Err, fail, sin if you must, but be upright. To sin as little as
> possible is the law for men; to sin not at all is a dream for angels."
>
> - Victor Hugo, "Les Miserables"
>
>
>
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Michael Douglass <mi...@texas.net>.
On Fri, 28 Jun 1996, Michael Douglass wrote:
> On Fri, 28 Jun 1996, Alexei Kosut wrote:
>
>>> <code>
>>> <img ismap src="blah.map.gif">
>>> </code>
>>>
>>> Causes a Segemetation Violation, and the that
>>> daemon core dumps. Unfortunately I can't
>>> find the core file.
>>
>> This is no doubt due to the fact that you, again, are having the file
>> parsed by the imagemap handler, and it is not expecting a GIF, but a text
>> file with imagemap rules.
Hopefully I'm not too far off field here, but it is definitely the case
and the problem seems very likely to be a buffer overflow. Of course, this
is just at first glance; but I can see how a binary file in the following
code (where a text file is expected) can cause problems. Hrm.. Seems
to me that this would be the problem with that:
*** snip ***
char input[LARGEBUF] = {'\0'};
char directive[SMALLBUF] = {'\0'};
*** snip ***
if (sscanf(input, "%s %s", directive, value) != 2) {
continue; /* make sure we read two fields */
}
*** snip ***
I can think of two easy ways to make sure that the server doesn't core
because of it. One, make directive and value both LARGEBUF so that they
are never overflowed; or two calculate the sizes of the two items before
doing the sscanf and making sure that they will fit in a SMALLBUF.
ie.
endpoint = strchr( input, ' ' );
if ( endpoint - input > SMALLBUF ) {
RETURN ERROR STATEMENT ABOUT MAP FILE BEING INVALID AND EXIT
}
Michael Douglass
Texas Networking, Inc.
"To be a saint is to be an exception; to be a true man is the rule.
Err, fail, sin if you must, but be upright. To sin as little as
possible is the law for men; to sin not at all is a dream for angels."
- Victor Hugo, "Les Miserables"
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Michael Douglass <mi...@texas.net>.
On Fri, 28 Jun 1996, Alexei Kosut wrote:
> > <code>
> > <img ismap src="blah.map.gif">
> > </code>
> >
> > Causes a Segemetation Violation, and the that
> > daemon core dumps. Unfortunately I can't
> > find the core file.
>
> This is no doubt due to the fact that you, again, are having the file
> parsed by the imagemap handler, and it is not expecting a GIF, but a text
> file with imagemap rules.
Hrm... Shouldn't there be code to make sure that we are reading in a text
file? Or at least do some sanity checking that prevents the core dump?
I'll try taking a look at the mod_imap.c and see if I can discover where
the SEGV is coming from and see what can be done.
Michael Douglass
Texas Networking, Inc.
"To be a saint is to be an exception; to be a true man is the rule.
Err, fail, sin if you must, but be upright. To sin as little as
possible is the law for men; to sin not at all is a dream for angels."
- Victor Hugo, "Les Miserables"
Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Posted by Alexei Kosut <ak...@organic.com>.
On Thu, 27 Jun 1996, Rob Hartill wrote:
> If you have a file referenced in a <code>
> <a href=" "> </a> </code> then Apache tries
> to give you a menu, even if the .map isn't at
> the end of the file.
That's correct. This is a feature of Apache 1.1. The "map" (assuming that
it is so configured - see srm.conf) tells Apache to treat the file as an
imagemap rule file. After that, the "html" simply tells Apache to display
the results as HTML by default (unless something else overrides it).
If you are not using imagemaps, you could take the appropriate line out of
your configuration files. Otherwise, you will have to rename your file to
"blah-map.html" or something else.
> <code>
> <img ismap src="blah.map.gif">
> </code>
>
> Causes a Segemetation Violation, and the that
> daemon core dumps. Unfortunately I can't
> find the core file.
This is no doubt due to the fact that you, again, are having the file
parsed by the imagemap handler, and it is not expecting a GIF, but a text
file with imagemap rules.
Thanks for using Apache!
-- Alexei Kosut <ak...@organic.com> The Apache HTTP Server
http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/