simon.proctor has asked for the wisdom of the Perl Monks concerning the following question:

I have to argue the point about using the NMS formmail over the one found here. I'm doing ok so far but I think it suffers from the poison null byte and I'm not sure if the test program I have written is correct.

I've taken the decoding section from the script which is used to decode the name and values from the CGI environment. Yes, this doesn't use CGI but thats on my list of errors (see below): 
s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

[download]


Now I've taken this snippet and I've created two files called 'test' and 'testtwo'. The idea is that I *should* open 'testtwo' but if theres the null byte then it opens 'test'. From what I can see it opens 'test' indicating the error.

Now to me, this is correct as all the snippet above does is decode the form data (and thats it). However, I'm about to out my neck out and so I'd love some feedback. My code follows (and the *current* list of errors with that script follow that). 
use strict;
use warnings 'all';


my $data = "d:\\test%00two";

print $data,"\n";

$data =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

print $data,"\n";

my $bob;
open FILE, "<$data" or die "Cannot open $data: $!\n";
{
    local $/;
    $bob = <FILE>;
}
close FILE;

print $bob;

[download]


Note that its hardcoded to my 'd' drive so if you want to run it, you'll have to create the files and change the path. I put 'in test' and 'in test two' in the respective files.

My list of errors (for the interested) is currently: 
Problems:

1) Does not use strict 
2) Does not use warnings
3) Does not use taint
4) Does not use the standard CGI module
5) A patch to Matts script version 1.6 - seeing as its now at 
   version 1.92 why not patch that?
6) Sendmail is called by -t and not by -oi -t
7) No attempt made at checking data length of posted data and
   thus preventing posts of arbitrary size
8) No attempt at checking the content type of the post thus
   allowing multi-part form data and thus arbitrary length uploads
9) No attempt at stopping uploads
10) The programmatic environment is not cleaned up, ie things not
    relating directly to the execution of the program are not 
    deleted (i.e. IFS CDPATH ENV BASH_ENV)
11) Makes use of arbitrarily declared globals in and out of routines
    and doesn't even use 'use vars'.
12) No error trapping on the sending of the email (or in the program
    at all). For example, using Carp or even 'local $SIG{__DIE__}'
13) Does not allow for mailing list references within a form and thus
    hiding all emails within the web page and prevent spam harvesting.
14) Appears to suffer from the poison null byte issue.

[download]
Though of course I'm still working on it :)

Replies are listed 'Best First'.
Re: Poison null byte test
by IlyaM (Parson) on Jul 26, 2002 at 09:24 UTC
    I think that version of formmail is safe from poison null byte expoloits. Perl itself doesn't treats null byte specially. It have special meaning only to system libraries so it can be exploited only when you pass filenames with null byte to functions like open.

    I've made quick review of that code and I have found only two open calls. Both of them do not use user supplied input for filenames.

    Read this Phrack article which describes how poison null byte expoloits work.

    Update: On the other hand I see that user supplied data is feed to sendmail as it is without escaping any bad chars (watch for print MAIL lines). It seems it can be used to inject additional mail headers into message. I'm not sure how it can exploited.

    Also there are XSS issues. It seems that user input is used to render HTML page without escaping any bad chars. Even if it is true it is unlikely to be exploitable since only user who submits form sees that page. Still it stinks.

    --
    Ilya Martynov (http://martynov.org/)

[reply]
[d/l]

Back to Seekers of Perl Wisdom