OT run ticker source code

[Fairlight]

Yo, homey, in case you don' be listenin', Howie done said:
> I am not a PERL programmer.  I was given the code for scrolling by someone 

Doesn't matter what you program in, umask 0 is unacceptable on any system.

> 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 

You found CGI code on the web and used it without understanding what it
does or why it does it?  That practise will eventually bite you.

> 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.

I'd have to see source code of the other applications that do make use of
it to tell you whether or not they're holed.  Depends if the qual field is
ever passed to system() or used unsanitised in any command.  If it is, it's
insecure.  If it's not, it may not be a problem, just extremely poor form.

> 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.

Actually, in Firefox, it shows nothing.  It did use favicon.ico on the tab,
which gave me the hint I should view source.  You're using more JS that
doesn't work in Firefox.  IE market share is falling.  Get used to
supporting multiple browsers.

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

You assume it does anything on the client end.  Didn't here.  You don't
even -KNOW- what your software is doing on the remote end.  That's supposed
to inspire confidence?  You obviously tested with around oh...one browser
model and called it good.

> 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.

Specifically, umask 0 will force directories to be created 0777, and files
to be created 0666.  Public writeable files are susceptible to spurious and
malicious data injection, quota bypassing, filesystem denial of service,
and a few other not-so-nice issues.  The fact that the files are -readable-
by anyone other than the users involved means that if you have any users
on the system that shouldn't be getting access to that data--they can
anyway.  The fact that the files are writeable means that someone could
modify the contents or abuse the system in other ways.  Using umask 0 or
chmod 0777|0666 is something to be avoided at all costs wherever possible.
Possible exceptions are devices, socket inodes, and named pipe inodes, but
those are special exceptions.

As for qual...I can't say if it is or isn't a security risk for your other
code.  As it sits in the current released code specific to the ticker, no,
I can't think of a way that it could be abused to bypass security -in that
particular application-.  It's the idea that you purportedly have similar
code elsewhere in more complex systems that worries me.  If unsanitised
data comes anywhere -near- a command line...  Okay, specific example...
Let's say you have a command that uses -M qualifier for clerk, ok?  Now,
you have zero sanitation in effect (at least from what you've shown)
for shell metacharacters.  Let's say some wiseass puts in an encoding
of "qual=word;rm -rf /;" for submission.  Unless you sanitise that for
metacharacters, what you could end up with is:

rclerk table -z whatever.prc -M word;rm -rf /; -s0 [... other args ...]

Okay, and what's that do when fed to system()?  Why, it tries executing the
rclerk up to the first semicolon (which should likely hang unless -sN and
an index was specified before the point of injection, waiting forever at a
selection screen), then goes on to remove everything the active UID owns,
system-wide, and just fails the third command because -s0 isn't actually
a command.  The fact that the command after it would fail is irrelevent,
since the rm is already in progress and merrily eating files.

I'm assuming you're passing a qualifier for a reason or you wouldn't be
passing it.  If you're not using it only through PFQUAL, but with something
like the -M flag, and you're not sanitising your data...well, you're
screwed, sorry.

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

You know, that would mean a lot more if my knowledge was valued enough
for you to read the list of general security considerations to which I
posted the URL.  You don't have time?  Hey mate, it's your system, feel
free to roll the dice.  I try to help with a -comprehensive- list of CGI
no-no's (probably one of the most comprehensive and complete currently in
existence, as many are smatterings and subsets--that's WHY I wrote it),
and you blow it off as unimportant to your purposes.  Okay, fine...I just
told you one -specific- use of non-sanitised data can ruin the rest of your
month if you do something the wrong way.

But that's -one- practise, and it's -one- example, Howie.  You obviously
don't understand the general underlying concepts behind what you're working
with, both at the OS and at the application level.  And working in a CGI
environment is just plain hazardous unless you have both systems knowledge
and knowledge about general tenets of CGI security.  I think there are
something like 20 or 22 other points in the CGI article I pointed you to.
So feel free to use this specific information, but you're more than likely
to fall prey to another dangerous practise of which you could have been
aware had you taken the time.

Using umask 0?  Basic lack of understanding of *nix filesystem security is
indicated.  There's no pulling of punches here; you just don't know it--or
if you do know it, you flat out don't care.  Take your pick.  But nobody
that knows what they're doing at the systems level would actually use this
with a straight face, much less publicly publish it and attach their name
to it.  I have a whole article dedicated to describing the why's and
wherefore's behind how it all works.  Will you read it?  No.  Why?  You
don't have the time.

And this is where I start getting more than testy--I get downright ticked.
Anyone not wanting to read a bit of venom, stop now and hit delete.

<RANT>

Give me ONE good reason, besides charity, that I should take the time I did
to give you a -specific- example, since you're too "busy" to get off your
rear and learn the WHOLE PICTURE so you don't shoot yourself in the foot.
Please, do.  I'm not seeing it.  I made those articles available ages ago.
The URL's were posted to the list.  I could dig up archive references if I
thought it was worth the time.  You'd -think- that if you're working on,
say...a *nix system, and working with, say...CGI, that you'd actually have
taken the time to at least GLANCE at them and see if you missed
anything--at the time of original posting.  Hell, Bill Campbell's been
doing CGI as long as I have and *nix a lot longer than me, and -he-
bothered with at least the CGI one, as evidenced by a reply at the time,
complimenting my article.

Now, you just got a -repeat posting- FOR YOUR BENEFIT, and you "don't have
the time" to be troubled with it?  Tell me why I should have had the time
to do what I just did in explaining it just for you, specially, gratis,
when I've already done it in general form.

You can't.  You know why?  No justifiable reason besides wanting to be
spoon-fed. 

And no amount of false and flowery flattery will erase that conclusion.

This reminds me why I got out of running public service web sites back in
August 2000:  Nobody -actually- values what you do for them if you do it
your way for general consumption and not catered specifically to them.
They want it their way -and- free.  That SO doesn't wash with me.

You have the URL's to the articles.  If you can't be troubled further to
better your programming and systems practises, well my conscience is clear.
I went out of my way to help you despite your attitude, but that's as far
as I'm going for free in a public forum.  Technically I shouldn't have
gone this far, IMHO, but if I hadn't, someone out there might go, "Well,
he doesn't know, OBVIOUSLY, because there was no answer...must be full of
it."  And then -my- reputation suffers because of your laziness.  So fine,
you forced my hand into a specific example.  I guarantee it wasn't for your
benefit at that point.  It was when I listed the articles.  On this one,
no.  I'm to ticked to even -want- to be of personal help to you at this
point.

"I don't have the time..."  Rubbish!  System security -demands- time.  Take
that time, or learn the hard way down the line.  Bottom line.  You'll be
wishing that you'd taken the time someday if someone wipes several key
parts of your system (or worse, selectively mangles it) and you spend WEEKS
putting back together what never need have been broken if you'd taken 15
minutes to read and comprehend a simple checklist, and put those practises
into practical use.

</RANT>

We now return you to your regularly scheduled blissful ignorance.

mark->
-- 
"Scrape 'em off, Claire...scrape 'em off!"  --Frank Cross
cross: 1) noun; A thing they nail people to.