"Miller, Matt" wrote:
>
> > And those "extreme" weaknesses would be what?
>
> How about various remote root exploits in apache, bind, procmail, sendmail,
> etc...?-- just to name a few of the obvious. Read the revision histories on
Remote root exploits in apache? The paper you link to below doesn't say
anything about root exploits through apache - just dumb configuration
problems that may lead to root exploits. They're about as valid as
saying "if you set your root password to something easily guessable,
people can log into your box as root."
BIND exploits are only valid if you're running bind as the 'root' user
which, as far as I know, most distributions don't do anymore and haven't
done for a while. Bind is pretty traditionally insecure though and
people who are aware of security issues do their best to sandbox bind
away from anything important.
Sendmail has also traditionally been considered insecure, but I haven't
seen any exploits for it in the last couple of years - since they went
commercial and put serious effort into rewriting the codebase and really
taking a proactive security stance on the product.
Procmail I have no opinion on since I don't have any information about
any exploits.
> these products/services. Arguably these root exploits aren't necessarily
> Linux specific, but inherent in any UNIX style OS running standard remote
> services. Typically these exploits are a result of buffer overflows --
> sounds familiar, huh?
Familiar in the sense that I see many more critical buffer overflow
exploits with such basic user-mode applications like IE and Outlook
under Windows that can compromise the entire system's security or that
there are buffer over exploits for things like bind or sendmail that are
system-level processes that run on UNIX boxes?
Find me a buffer overflow in Mozilla or Netscape or Konqueror that can
give a remote user root access on my box if I'm running it as an
unprivileged user under Linux and I'll grant you your point.
I won't even try to challenge anyone to find exploits that allow
adminstrative access through IE or Outlook running as a normal user
because that's like shooting fish in a barrel. Dead fish. In a very
small barrel. With a really big gun.
> Up until recently*, almost all DoS attacks have come
> from compromised UNIX based servers.
References?
> * until of course microsoft deployed a raw sockets tcp/ip stack with Win2000
Bogus argument. Raw sockets capability has been in Windows forever.
It's just that script kiddies don't make use of them. (Thank you Steve
Gibson for running around yelling "The sky is falling! The sky is
falling!")
> Attached are some links from SANS:
>
> http://www.sans.org/infosecFAQ/sysadmin/apache.htm
See above comments.
> http://www.sans.org/infosecFAQ/DNS/sec_BIND.htm
This one actually looks pretty well-written. Like I said, BIND is the
worst offender. Smart admins don't let it have any privileges on their
systems whatsoever because of this.
> http://www.sans.org/infosecFAQ/threats/top_ten.htm
Most of these listed are non-Linux related, or again, just dumb
configuration mistakes. (Again, one of the issues is actually "User
ID's, especially root/administrator with no passwords or weak
passwords.") There's no way you can keep a dumb admin from doing dumb
things to leave their machine open to attack except teach them how not
to be dumb.
My original point, and what I was refuting from the original post is
that the BASIC SECURITY MODEL of Windows is so sorely broken when you
compare it to a REAL SECURITY MODEL like that of a traditional UNIX
system that it's insanity to say that Linux/UNIX is less secure than
Windows, or inherently insecure. Sure you can MAKE a Linux box
insecure, but you can also secure a UNIX box much better than you can a
Windows machine.
Try this:
as a "normal, unpriviledged" user on a Windows box, run the command:
"format c:"
as a "normal, unprivileged" user on a Linux box, run the command: "rm
-rf /"
see which one has a better security model.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.eff.org/ http://www.opendvd.org/
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:57:55 EDT