Skip to main content.
home | support | download

Back to List Archive

Re: Swish-e CGI script security?

From: Bill Moseley <moseley(at)>
Date: Thu May 18 2006 - 14:34:15 GMT
On Thu, May 18, 2006 at 03:05:19PM +0100, David Brooks wrote:
> OK. I'm finding the apache error log very puzzling. I'm used to seeing 
> nicely timestamped entries, but I assume it will just logs whatever gets 
> spat out by CGIs because there is no timestamp for these entries.

Anything written to stderr will end up in the apache error log as-is.

But, I'd like to see the access.log entries to see what request is,
although if it's a post that won't help much, but it will be helpful
to try and match up request and the error log entries.

> Because of this, I could be completely barking up the wrong tree - the 
> Perl errors might have happened some time earlier and be unconnected... 
> although I don't think I've seen them occur before.
> /var/www/mysite/search.cgi aborted: Timed out
> Use of uninitialized value in concatenation (.) or string at 
> /usr/lib/swish-e/perl/SWISH/ line 49.

The script will kill swish if the query is taking too long to run.
That should not happen very often, so that's odd.

> Use of uninitialized value in concatenation (.) or string at 
> /usr/lib/swish-e/perl/SWISH/ line 282.

What's line 282 look like?

> --18:58:48--
>            => `gif.txt'
> Resolving
> Connecting to[]:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 17,325 [text/plain]
>     0K .......... ......                                     100% 
> 74.60 KB/s
> 18:58:48 (74.60 KB/s) - `gif.txt' saved [17325/17325]
> kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or 
> kill -l [sigspec]
> Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at 
> /usr/lib/perl/5.8/ line 201.
> join: too few non-option arguments
> Try `join --help' for more information.

That sure looks like someone running wget and trying other commands.
Luckily, wget spits out the current time.  What access.log entries do
you have around 18:58?

The swish.cgi script does not use, so I'm wondering if
there's not another script involved.

The script runs swish via the exec system call, not through the shell.
So, user data is not able to access the shell.

sub real_fork {
    my ( $conf, $self ) = @_;

    # Run swish
    my $fh = gensym;
    my $pid = open( $fh, '-|' );

    die "Failed to fork: $!\n" unless defined $pid;

    if ( !$pid ) {  # in child
        unless ( exec $self->{prog},  $self->swish_command_array ) {
            warn "Child process Failed to exec '$self->{prog}' Error: $!";
            print "Failed to exec Swish";  # send this message to parent.
    } else {
        $self->{pid} = $pid;

    return $fh;

> Of course. But if I'm familiar with the language that helps me rather a 
> lot when it comes to looking at the code and seeing if it's sane. I 
> assume this Perl CGI is sane based purely on the fact I got it out of 
> debian stable.

Right, it's hard to know without looking at the code yourself.
Stable means more that the packages work together, not that the code
is secure.  That's why there's security fixes.  The downside is that
you end up running old code.

> I just realised those errors refer to a Perl file I had copied then 
> edited to make the HTML output match my site... if you want me to send 
> more logs and a copy of that file, I'd be happy to take it off list if 
> its going to be disruptive. Also if you think this is something else 
> I've goofed up and isn't Swish related, that's fair enough - thanks for 
> your time all the same.

Yes, please.  Need to figure out exactly what is happening.

Bill Moseley

Unsubscribe from or help with the swish-e list:

Help with Swish-e:
Received on Thu May 18 07:34:17 2006