OT run ticker source code

[Howard Wolowitz]

Top Posted

I am not a PERL programmer.  I was given the code for scrolling by someone 
at Aljex who found it on the web.  I have no idea of what "perldoc CGI" is 
or does or how I might use it.  I am parsing the entire query string because 
that's the code I found on the web and, in the original application, only 
the qual= variable is being passed (and it is encoded too.)  You are right 
though, I don't need it for this application at all but I didn't want to 
take the time to remove it.  (I wrote this application in 1/2 hour by 
modifying the original)  In the original application the qual= identifies 
the company (by using a random code that is contained in a filepro file that 
then tells the system the real filepro qualifier for that company).  If an 
invalid or missing value is sent then the applications just announces a bad 
qualifier error and ends.

If you want to see the original application use:

http://nj.aljex.com/loadsticker/tickx.pl?qual=bj262j10

It shows the pickup date, the equipment type and the from and to city and 
states.  It is also color coded so overdue pickups are shown in red.

Once it is scrolling you can click on any load's date to view more 
information in a separate window.

If you will, please explain how you could exploit the security issues you 
have raised.  Don't ask me to read generalized guidelines as I don't have 
the time and probably wouldn't understand them anyway.  Just treat me as the 
humble filepro programmer that I am.  I _do_ have time to read your response 
and I am asking specifically how this application could be used in an attack 
on our server.

Your help in clarifying it would be of immense value to me and I suspect 
others as well.

Thanks,

Howie



----- Original Message ----- 
From: "Fairlight" <fairlite at fairlite.com>
To: "filePro List" <filepro-list at seaslug.org>
Sent: Friday, May 12, 2006 1:09 PM
Subject: Re: OT run ticker source code


> >From inside the gravity well of a singularity, Howie shouted:
>> Once everything is in the proper place, with the proper permissions you
>> start it by running:
>
> You speak of proper permissions?  From runticker.bat:
>
> umask 0
>
> Insecure, 'nuff said.
>
>>From tick.pl...why are you doing CGI parsing by hand when there's a module
> that does it properly already?  perldoc CGI
>
> For that matter, I'm lost on the $qual=$value line.  That makes no
> sense.  You go to the trouble of parsing and urldecoding every name=value
> pair in $QUERY_STRING, then you just seem to assume the last value
> present will correlate to a value you can use for 'qual'.  A wholly
> unfounded assumption, I might add.  If that were the case, you could have
> skipped 11 lines of code and altered one and just assumed you could split
> qual=whatever.
>
> To top it off, there's absolutely zero sanitation of $qual, and you just
> spit it back out in tick.pl.  That's the only place it seems to be used in
> any sort of logic or output, despite appearing in ticker.pl, tickref.pl,
> and tick.pl.  Actually, you do the full QUERY_STRING parse in all three,
> despite the fact you never seem to actually -use- what you're trying to
> get.
>
> I have zero idea what you're using it for, but boy, this is not pretty 
> code
> in general.  Considering the lack of sanitisation, I'm -glad- for you that
> $qual isn't actually used anywhere important in this.
>
>> Once you understand how it all works you can modify it to display any 
>> type
>> of information you want.  At Aljex the original version was created to
>> display all shipments waiting to be dispatched.  The qual= variable (not
>> used in runticker) was for passing the user's qualifier name to filepro.
>
> Ah, well, that's what I get for answering inline.  However...if it's not
> used, why is it there?  If it's used with the same lack of sanitation and
> the same assumptions about being the last value that you have here, but in
> your other programs...you have some security issues that want addressing.
> The umask is just plain inexcusable in any area.  I suggest a look at
> either cgiwrap or suEXEC so you can get out of this mindset (present since
> fpWeb, from what I've seen on people's systems) that you must let
> everything be 0777 to work with files between apache and filePro.  I'm
> surprised this approach hasn't been modified in the years since you were
> made aware that it's an inherently bad practise.
>
>> PS: I made some last minute changes to clean up the code and scripts and
>> hope I have not introduced any bugs.
>
> It's just needlessly bloated.
>
> The JS stuff was a bit informational, at least.  I'm not sure how much I
> trust it as a "good example" after seeing it directly associated with some
> of the worst CGI I've seen coming from outside the Ukraine, but it was
> informational nonetheless, thanks.  (Actually, considering what it did to
> Firefox's main window, I would hazard there are some bad assumptions being
> made in the JS as well.  In fact, I'd state it as probable.)
>
> I'm sorry.  I mean...I sincerely believe you want to share something neat
> with the community, and I applaud that.  But this stuff is just...I mean 
> if
> you say you cleaned it up, and it's in that state, I have to question your
> definition of "clean" CGI.  It's nothing I would personally put -near- a
> web server on a public network.
>
> http://www.fairlite.com/fc/articles/
>
> I'd suggest reading both the one on basic CGI security, and the one on
> *nix filesystem permissions.
>
> mark->
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>