Once there was a company durring the dot.com boom. This company had
some outside consultants come in and tell them how to do a number of
things. Many of the things were laughed off but some stuck. 2 things
in particular are giving me nightmares now that I'm at this company.
They have survived the bust and I think will actually stand a very good
chance to be very important in the near future so I want to see them
stay sane, stable and secure.
The consultants aparantly told the company admins that kernel modules
were a massive security hole and extremely easy targets for root kits.
As a result every machine has a 100% monolithic kernel, some of them
ranging to 1.9Meg in filesize. This of course provides some other
sticky points such as how to do a kernel boot image.
I'd like it from the guru's on exactly how bad a hole this really is
and if there is a method in the kernel that will prevent such exploits.
For example, if I disable CONFIG_MODVERSIONS is the kernel less likely
to accept a module we didn't build? Are there plans to implement some
form of finger printing on modules down the road?
Thanks for your imput guys,
Robert
:wq!
---------------------------------------------------------------------------
Robert L. Harris
DISCLAIMER:
These are MY OPINIONS ALONE. I speak for no-one else.
FYI:
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
On Wed, 23 Oct 2002, Robert L. Harris wrote:
> I'd like it from the guru's on exactly how bad a hole this really is
> and if there is a method in the kernel that will prevent such exploits.
> For example, if I disable CONFIG_MODVERSIONS is the kernel less likely
> to accept a module we didn't build? Are there plans to implement some
> form of finger printing on modules down the road?
I seem to recall that there are rootkits with kernel modules out in the
wild. If I recall correctly, there is a kernel capabilities patch that
will disallow loading modules after some point.
Its been something I've been meaning to look into more, but with a million
other projects on the platter ...
--
-- John E. Jasen ([email protected])
-- User Error #2361: Please insert coffee and try again.
On Wed, 23 Oct 2002 09:02:51 -0400,
"Robert L. Harris" <[email protected]> wrote:
> The consultants aparantly told the company admins that kernel modules
>were a massive security hole and extremely easy targets for root kits.
Typical consultant rubbish. Yes, LKMs can hide rooted systems, but the
system has already been broken into by then. You must be root to load
a module or copy a module to /lib/modules, depmod ignores modules that
are not owned by root. IOW, if somebody can load a module then they
already own your system!
Fingerprinting modules is a hardy perennial. It cannot be done in user
space (how do you fingerprint the loader, libc, insmod etc.?), it can
only be done in kernel. No kernel code exists to do that, although LSM
may be getting there. The stumbling block is - who creates the
fingerprint? Answer - root. You are trying to identify the difference
between a valid root user and a malicious root user, both of whom have
exactly the same privileges. It does not work!
LSM with its fine grained security model might help in this area, but
don't hold your breath. LSM has not been accepted into the kernel yet.
>As a result every machine has a 100% monolithic kernel
There are techniques for getting the same effect as LKMs even when the
kernel is not compiled with modules. Phrack had a series of articles
on this subject. Turning off modules increases the effort of hiding
the break in by 5-10%, it does not make the system any more secure.
Remember, if somebody can load a module then they have already broken
in.
On Wed, 2002-10-23 at 14:02, Robert L. Harris wrote:
> The consultants aparantly told the company admins that kernel modules
> were a massive security hole and extremely easy targets for root kits.
> As a result every machine has a 100% monolithic kernel, some of them
> ranging to 1.9Meg in filesize. This of course provides some other
> sticky points such as how to do a kernel boot image
Modules make no difference to security. If I can add a module I can swap
the kernel and reboot the box, or I can patch the kernel. In fact I can
load modules into module-less kernels its just a bit harder.
> to accept a module we didn't build? Are there plans to implement some
> form of finger printing on modules down the road?
It doesnt help you without a lot more than just fingerprints. You can
revoke module loading at boot time if you want - it only makes things a
little harder.
If you want to make it theoretically impossible then you need to load
the modules required early then revoke the module loading and rawio
capabilities. At that point I should not be able to get raw hardware
access or load a module. You need to revoke both of the so I can't for
example hand load modules by poking in /dev/mem.
Alan
On Wed, 2002-10-23 at 15:45, Alan Cox wrote:
> On Wed, 2002-10-23 at 14:02, Robert L. Harris wrote:
> > The consultants aparantly told the company admins that kernel modules
> > were a massive security hole and extremely easy targets for root kits.
> > As a result every machine has a 100% monolithic kernel, some of them
> > ranging to 1.9Meg in filesize. This of course provides some other
> > sticky points such as how to do a kernel boot image
>
> Modules make no difference to security. If I can add a module I can swap
> the kernel and reboot the box, or I can patch the kernel. In fact I can
> load modules into module-less kernels its just a bit harder.
IMHO the security risks associated with modules is not the potential for
getting higher permissions but rather that having the loadable module
capability makes it *easier* to hide your code and actions once you're
in because what you would want to do is change the running kernel to
hide your actions and loadable modules makes it easier to dynamically
change a running kernel in general (DUH! :-). In short - LKM support
doesn't open any doors; It does makes it slightly easier to stay
invisible once you're in.
There are, again IMHO, much simpler things that I'm willing to bet
company X isn't doing (because no one is doing them) that would help
much more to security then disabling LKM support. For example - when you
download a new update of a kernel (or any program for that matter)
source/patch (or binary package) from the net do you check the GPG
signature validity? I would be VERY surprised if you answer 'yes'...
:-))
Gilad.
>
> Alan
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Wed, 23 Oct 2002, Robert L. Harris wrote:
> The consultants aparantly told the company admins that kernel modules
> were a massive security hole and extremely easy targets for root kits.
> As a result every machine has a 100% monolithic kernel, some of them
> ranging to 1.9Meg in filesize. This of course provides some other
> sticky points such as how to do a kernel boot image.
It's the typical so-called Security Consultant's lies. After all,
if they knew what they were doing you wouldn't need them. They
create phony scenarios and then "solve" them. For instance, they
will load a module using a "root kit". Look, your system needs to
have been broken into in order to load a module. It's already been
broken into, the module is just a Security Consultant lie.
To load a module, you need to be root. If you are root and you
shouldn't be, the system has been broken into. It's just that
simple. It's not possible for `insmod` or `depmod` to load a
module, sitting in a rogue user's directory, that suddenly gives
that rogue user some privileges that he or she didn't already have.
We had some Security Consultant idiot from some well-known
auditing agency declare that all Linux machines were vulnerable
to outside attacks and "continuing use of such software
could result in a investor lawsuit..."
Of course the attack against Linux was "true". If you put a
Linux machine (or Sun or whatever), on the outside of a firewall
it may be attacked, therefore vulnerable to attack. And, if
investors learned that you were so stupid as to put it outside
a firewall, you might get sued by the investors. It's all perfectly
true. It's a trick by liars that lie by telling irrefutable
truths.
In a similar scenerio, a Windows machine might not even be attacked.
There is nothing to be gained, even as the operating system is
compromised. It would likely crash before any proprietary information
could be obtained. One of the advantages of Windows is that it's
so awful that only GWBASIC users are interested in it, then only
to change the location of a GOTO ;^.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
"Robert L. Harris" <[email protected]> writes:
> I'd like it from the guru's on exactly how bad a hole this really is
>and if there is a method in the kernel that will prevent such exploits.
>For example, if I disable CONFIG_MODVERSIONS is the kernel less likely
>to accept a module we didn't build? Are there plans to implement some
>form of finger printing on modules down the road?
You can get the same effect as a module with a kernel without any
modules support compiled. There are even root kits out there which do
exactly this.
If you want a little more security, don't run a vendor kernel
(sic!). Not because they're unsafe but because many rootkits have
binary modules for some well known kernels (2.4.9-34 or 2.4.18-3 come
to mind); clean up your systems (e.g. don't ever ever ever have a
compiler and a development kit on an internet connected system. If you
don't have a compiler, 80% of all root kits will not work or will
simply not be able to build the process hiding stuff because it comes
as C code). If you run 2.4.18-3-rerolled with MODVERSIONS off, lots of
the kiddie root kits break.
You can't get security by design. Ask the OpenBSD people who tried
this and failed.
You get security by installing your systems, administrating them
(which means looking at logfiles, unusual activities), keeping your
boxes up to date with vendor patches and by training your staff to be
security aware. Read lists like Bugtraq. Invest time (and money!) in
the security of the systems.
If some consultant sets up a box and slaps a "this is safe" label on
it, start being suspicious. I've seen more than my share of RedHat 5.x
and 6.x boxes which were installed like this and then they called me
12 months later because the "so secure" boxes have been rooted...
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Wed, 23 Oct 2002, Richard B. Johnson wrote:
>
> Of course the attack against Linux was "true". If you put a
> Linux machine (or Sun or whatever), on the outside of a firewall
> it may be attacked, therefore vulnerable to attack. And, if
> investors learned that you were so stupid as to put it outside
> a firewall, you might get sued by the investors. It's all perfectly
> true. It's a trick by liars that lie by telling irrefutable
> truths.
Actually at the place that just went bankrupt on me I had a Security
consultant complain that 2 of my servers were outside the firewall. He
recommended that I get a firewall just for those 2 servers but backed off
when I pointed out that I would need to open all of the same ports that
are open on the server anyways so the vulnerability isn't any less with
the firewall.
Firewalls are another Security Consultant's lie and using them for
anything other than preventing outside connections to internal machines
and keeping certain DOS attacks outside the network is a waste of money.
To top it off they make admins feel safer so they are less likely to make
sure the machine is actually admined properly.
Never trust Security Consultants.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
yes someone who has root can get the effect of modules by patching
/dev/kmem directly so eliminating module support does not eliminate all
risk.
it does however eliminate the use of the rootkits that use kernel modules.
you need to decide if the advantages of useing modules are worth it for
your situation.
what do you compile into a kernel to make it 1.9M compressed? I suspect
that you could trim that down to fit a floppy for a rescue disk. In
addition you may want to consider making your rescue disk be a CDROM so
that you can not only fit a larger boot image, but you can also fit more
untilities to help you work on the system.
also there are a couple ways to make a CD bootable.
One way is to use the floppy image (I think it's called El Torito or
something like that)
In addition I have created bootable CD's with lilo and ext2 partitions. If
it's an IDE CDROM you can setup a CD to treat it like a read-only IDE
drive (or you used to be able to anyway, I haven't checked it since 2.2
days)
David Lang
On Wed, 23 Oct 2002, Henning P. Schmiedehausen wrote:
> Date: Wed, 23 Oct 2002 16:23:13 +0000 (UTC)
> From: Henning P. Schmiedehausen <[email protected]>
> To: [email protected]
> Newsgroups: hometree.linux.kernel
> Subject: Re: One for the Security Guru's
>
> "Robert L. Harris" <[email protected]> writes:
>
> > I'd like it from the guru's on exactly how bad a hole this really is
> >and if there is a method in the kernel that will prevent such exploits.
> >For example, if I disable CONFIG_MODVERSIONS is the kernel less likely
> >to accept a module we didn't build? Are there plans to implement some
> >form of finger printing on modules down the road?
>
> You can get the same effect as a module with a kernel without any
> modules support compiled. There are even root kits out there which do
> exactly this.
>
> If you want a little more security, don't run a vendor kernel
> (sic!). Not because they're unsafe but because many rootkits have
> binary modules for some well known kernels (2.4.9-34 or 2.4.18-3 come
> to mind); clean up your systems (e.g. don't ever ever ever have a
> compiler and a development kit on an internet connected system. If you
> don't have a compiler, 80% of all root kits will not work or will
> simply not be able to build the process hiding stuff because it comes
> as C code). If you run 2.4.18-3-rerolled with MODVERSIONS off, lots of
> the kiddie root kits break.
>
> You can't get security by design. Ask the OpenBSD people who tried
> this and failed.
>
> You get security by installing your systems, administrating them
> (which means looking at logfiles, unusual activities), keeping your
> boxes up to date with vendor patches and by training your staff to be
> security aware. Read lists like Bugtraq. Invest time (and money!) in
> the security of the systems.
>
> If some consultant sets up a box and slaps a "this is safe" label on
> it, start being suspicious. I've seen more than my share of RedHat 5.x
> and 6.x boxes which were installed like this and then they called me
> 12 months later because the "so secure" boxes have been rooted...
>
> Regards
> Henning
>
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
> D-91054 Buckenhof Fax.: 09131 / 50654-20
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Followup to: <[email protected]>
By author: David Lang <[email protected]>
In newsgroup: linux.dev.kernel
>
> yes someone who has root can get the effect of modules by patching
> /dev/kmem directly so eliminating module support does not eliminate all
> risk.
>
> it does however eliminate the use of the rootkits that use kernel modules.
>
> you need to decide if the advantages of useing modules are worth it for
> your situation.
>
One thing about all of this that matters is the following:
It's not about how secure your system is.
It's about how smart/well equipped/patient the attacker needs to be
*once they have already broken into your system*.
I recently had one of my machines broken into, but the service in
question was not running as root, and the attacker wasn't able to find
any privilege-escalation bugs on my system. I found a whole
collection of attempted security violations in a directory in /tmp,
and a daemon (called "bind" -- not "named") had been installed to get
access to my system again. Needless to say, I cleaned that stuff up,
and also got a close look at the rootkit.
Since my machine hadn't succumbed to the rootkit, it seems the
attacker had simply moved on. Most of these kinds of attacks are
actually automated these days, unless you're a high-value site for
them.
The kernel module, and/or replacing common user tools like ps, are
usually about trying to hide the existence of whatever
intrusion-installed software there is. It really helps more on
"springboard" site than sites that are the genuine attack targets.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On 2002-10-23, "Robert L. Harris" <[email protected]> wrote:
> The consultants aparantly told the company admins that kernel modules
> were a massive security hole and extremely easy targets for root kits.
Massive? Of course not. Easy target for root kits, sure, but only if
they've already been owned, first. Under normal circumstances (there
have been bugs in the past; iirc in kerneld for instance which let a user
trick the system into loading an arbitrary file as a module) one can't
load modules until one's already root, so the system would have had to be
compromised already. Trojaning the kernel is the best place for a
rootkit to live; why bother replacing individual tools (and hoping you
got them all, and that there's no static-linked integrity checker
somewhere) when you can just modify opendir(2), even read(2), etc to lie
for you?
4-5 years ago I would have (and did) recommend staying away from modular
kernels for this reason. But binary-patching a running non-modular
kernel has been well explored and is well-known; it's really no harder to
trojan a non-modular kernel than a modular one. Assuming you have not
taken steps to disallow raw io, /dev/kmem access, etc. If you are
willing/able to do that, then you can just insmod all necessary modules,
and then another one which disables further module-loading, drop the
necessary capabilities systemwide, etc. So again, modular/nonmodular
kernel doesn't matter much.
--
Hank Leininger <[email protected]>
On Wednesday 23 October 2002 06:59 am, Gilad Ben-ossef wrote:
> On Wed, 2002-10-23 at 15:45, Alan Cox wrote:
> > On Wed, 2002-10-23 at 14:02, Robert L. Harris wrote:
[ Snip! ]
>
> .... For example - when you
> download a new update of a kernel (or any program for that matter)
> source/patch (or binary package) from the net do you check the GPG
> signature validity? I would be VERY surprised if you answer 'yes'...
>
> :-))
>
> Gilad.
Be surprised: I run "gpg --verify foo.tgz.sign foo.tgz" every time I download
from kernel.org. And, "rpm --checksig *.rpm" on stuff from redhat.com too.
Given the recent trojaned source packages, I recommend that everyone do the
same.
= = = =
The preceding public service message has been sponsored by Anal Retentive
Sysadmins .Org (Motto: Constipation: It's not just a gob, it's a career!)
> > Alan
--
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
> The consultants aparantly told the company admins that kernel modules
> were a massive security hole and extremely easy targets for root kits.
> As a result every machine has a 100% monolithic kernel, some of them
> ranging to 1.9Meg in filesize. This of course provides some other
> sticky points such as how to do a kernel boot image.
i very much doubt this would stop anyone who really wanted todo
something like loading a module.
Stating something like that would also mean booting the kernel from
a disk inside the machine is also insecure.
As to load a module you must be root and if you are root you
can read / write disks. Thus you could recompile your own kernel
install it try to force a crash or a reboot which is not hard as root
and the person may not even notice that the kernel has grown by a few
bytes after the crash.
The only thing it may do is slow somebody down.
A lot of people out there if they can get access to a system
and cannot keep it will also tend todo a rm -rfv /
or equivelent nasty.
James
> Be surprised: I run "gpg --verify foo.tgz.sign foo.tgz" every time I download
> from kernel.org. And, "rpm --checksig *.rpm" on stuff from redhat.com too.
and when an attacker looks into your .bash_history see this and modifies
gpg and rpm ?
On Wednesday 23 October 2002 03:17 pm, James Stevenson wrote:
> > Be surprised: I run "gpg --verify foo.tgz.sign foo.tgz" every time I
> > download from kernel.org. And, "rpm --checksig *.rpm" on stuff from
> > redhat.com too.
>
> and when an attacker looks into your .bash_history see this and modifies
> gpg and rpm ?
First, I use ksh, so the kiddie is looking into the wrong history. ;^)
Second, I'm trying to keep him/her/git out by not loading a trojaned package.
Once the scumbag is inside your box, it's much harder to throw them out. In
fact, a reinstall is usually in order.
Third, if they don't do it already, I'd like kpackage, gnorpm, and similar
tools to always check signatures before loading a package. (And, for the GPG
public keys used to have come with trust signatures from the installation
CD.) That would really help with all the newbies to *nix coming on board
now.
PS: If you don't trust your gpg or rpm, boot off install CD # 1, switch to a
text console, and use the ones on the CD. QED. :^)
--
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
> Third, if they don't do it already, I'd like kpackage, gnorpm, and similar
> tools to always check signatures before loading a package. (And, for the GPG
> public keys used to have come with trust signatures from the installation
> CD.) That would really help with all the newbies to *nix coming on board
> now.
dont most of thoose only use a shared libary which would mean
1 file overwrite and disable all. Though rpm i know is normally static.
> PS: If you don't trust your gpg or rpm, boot off install CD # 1, switch to a
> text console, and use the ones on the CD. QED. :^)
heh by the time you dont trust it. Its normally time to reinstall.
On Thu, 2002-10-24 at 00:17, James Stevenson wrote:
>
> > Be surprised: I run "gpg --verify foo.tgz.sign foo.tgz" every time I download
> > from kernel.org. And, "rpm --checksig *.rpm" on stuff from redhat.com too.
>
> and when an attacker looks into your .bash_history see this and modifies
> gpg and rpm ?
When the attacker can look into the .bash_history of root he has already
taken over the box. As Alan already stated before on this thread, when
the attacker has root, the game is over anyway - what happens next only
effects how long it will take you to find out you have 'guests'.
The purpose of the GPG spiel is to stop (read: make it harder) from the
attacker becoming root in the first place, for example by replacing
packages you download (either on the ftp site or in trnasit) with
trojaned copies.
Gilad.
--
Gilad Ben-Yossef <[email protected]>
http://benyossef.com
"Geeks rock bands cool name #8192: RAID against the machine"
Robert L. Harris wrote:
> The consultants aparantly told the company admins that kernel modules
>were a massive security hole and extremely easy targets for root kits.
They were blowing smoke. Once the attacker has root on your machine,
you're toast, whether or not you have loadable modules enabled. The right
defense is to prevent attackers from getting root on your machine; the
consultant's recommendations are probably not the best way to spend your
time and energy.
On Wed, Oct 23, 2002 at 11:20:33PM +1000, Keith Owens wrote:
>
> LSM with its fine grained security model might help in this area, but
> don't hold your breath. LSM has not been accepted into the kernel yet.
Um, what's sitting in the security and include/linux/security.h files in
the 2.5 tree then? :)
In short, it's in, but not "every" part of it, yet.
thanks,
greg k-h
Gerhard Mack <[email protected]> writes:
>Actually at the place that just went bankrupt on me I had a Security
>consultant complain that 2 of my servers were outside the firewall. He
>recommended that I get a firewall just for those 2 servers but backed off
>when I pointed out that I would need to open all of the same ports that
>are open on the server anyways so the vulnerability isn't any less with
>the firewall.
So you should've bought a more expensive firewall that offers protocol
based forwarding instead of being a simple packet filter.
packet filter != firewall. That's the main lie behind most of the
"Linux based" firewalls.
Get the real thing. Checkpoint. PIX. But that's a little
more expensive than "xxx firewall based on Linux".
Actually, there _are_ security consultants, that know what they're
talking about. Unfortunately they're drowned out most of the time by
the drone of so called "self-certified Linux experts" which believe,
everything can be handled by using the only tool they know.
>Never trust Security Consultants.
BS. Invest money in real consultants that know their trade. They
simply might not be the cheapest and they might tell you solutions
that hurt (e.g. training your staff) but of course there are lots of
people that know what they're talking about.
Ciao
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
James Stevenson <[email protected]> writes:
>can read / write disks. Thus you could recompile your own kernel
Don't put a compiler on the box.
The point is not, to make it impossible to root your box. The point
is, to make it a) hard(er) and b) time intensive.
a) keeps out the kiddies with the r00t hAx0r kits
b) gives a security aware staff (or an IDS or a security watcher)
a reaction window.
One of the most sucking decisions of mainstream distributions is that
they offer to install a development kit on server installs. It seems
that people working @ linux vendors either have no clue or simply
don't understand the needs of their customers.
Sheesh, some even install a full desktop with "[gnome|kde]-games" on a
server. What is this? Microsoft Windows <insert your poison here>" ?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Thu, 2002-10-24 at 10:38, Henning P. Schmiedehausen wrote:
> Gerhard Mack <[email protected]> writes:
>
> >Actually at the place that just went bankrupt on me I had a Security
> >consultant complain that 2 of my servers were outside the firewall. He
> >recommended that I get a firewall just for those 2 servers but backed off
> >when I pointed out that I would need to open all of the same ports that
> >are open on the server anyways so the vulnerability isn't any less with
> >the firewall.
>
> So you should've bought a more expensive firewall that offers protocol
> based forwarding instead of being a simple packet filter.
>
> packet filter != firewall. That's the main lie behind most of the
> "Linux based" firewalls.
>
> Get the real thing. Checkpoint. PIX. But that's a little
> more expensive than "xxx firewall based on Linux".
>
Thats not entirely accurate, or fair. A packet filter is a type of
Firewall (or can be). A Firewall is a means to implement a security
policy, usually specifically a network access policy. A Packet Filter,
including a ""Linux based" firewall" is a perfectly acceptable means of
achieving that goal, if it meets the policy requirements.
Ref. http://csrc.nist.gov/publications/nistpubs/800-10/ (over 7 years
old, but still highly relevant).
Most commercial firewalls are very bad at protecting servers offering
Internet services, they aren't designed to do it.
-tony
On Wed, Oct 23, 2002 at 11:15:14PM +0100, you [James Stevenson] wrote:
>
> As to load a module you must be root and if you are root you
> can read / write disks. Thus you could recompile your own kernel
> install it try to force a crash or a reboot which is not hard as root
> and the person may not even notice that the kernel has grown by a few
> bytes after the crash.
Which is why some people configure kernels not to support installing modules
and only use read-only media (e.g. CD-R) for booting. Sure, there's still
the /dev/kmem hole, but this closes 2 classes of attacks - loading rootkit
module and booting with a hacked kernel in straight-forward way.
BTW, this might be a reason to make kexec syscall to be a config option (if
it isn't already.) The other reason is to avoid bloat for people that don't
need it, but perhaps this is a stronger argument. I realize you can propably
launch the kernel by hand (using /dev/kmem etc) if you really know what to
do. But the same applies to adding code/patching kernel without
CONFIG_MODULES support.
-- v --
[email protected]
Ville Herva <[email protected]> writes:
>the /dev/kmem hole, but this closes 2 classes of attacks - loading rootkit
>module and booting with a hacked kernel in straight-forward way.
Question: What do I lose when you remove /dev/kmem?
Related question: Would it be useful to make /dev/kmem read-only?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Thu, 2002-10-24 at 12:09, Henning P. Schmiedehausen wrote:
> Ville Herva <[email protected]> writes:
>
> >the /dev/kmem hole, but this closes 2 classes of attacks - loading rootkit
> >module and booting with a hacked kernel in straight-forward way.
>
> Question: What do I lose when you remove /dev/kmem?
> Related question: Would it be useful to make /dev/kmem read-only?
Makes no real difference. If the user got to root they can work the
chmod command. What you want to do is revoke CAP_SYS_RAWIO which kills
off all direct hardware access - mem/kmem/iopl/ioperm etc. It does stop
non kernel fb X working but thats not a big deal on a server.
On Thu, 2002-10-24 at 11:38, Henning P. Schmiedehausen wrote:
> So you should've bought a more expensive firewall that offers protocol
> based forwarding instead of being a simple packet filter.
>
> packet filter != firewall. That's the main lie behind most of the
> "Linux based" firewalls.
>
> Get the real thing. Checkpoint. PIX. But that's a little
> more expensive than "xxx firewall based on Linux".
AFAIK Linux has "protocol base forwarding" (more commonly known as
"state-full inspection") for *some* protocols.
Also, although Firewall-1 and PIX are very good products (and provide
income to some of my best friends :-), the implications that they are
somehow magically much better then the freely available ones is somewhat
misleading IMHO.
They certainly offer more *features*, the question is whether these
additional features indeed translate into better security. IMHO for most
cases the answer is negative. Again, this is not because they are not
good (or even better), but rather that they are better answer to the
wrong question - the TCP and HTTP stream is perfectly fine and legal and
the buffer overflow "hides" in the data payload but firewalls can't stop
that (unless it's a relatively old attack) and that is, again IMHO,
where the problems seems to be today.
>
> Actually, there _are_ security consultants, that know what they're
> talking about. Unfortunately they're drowned out most of the time by
> the drone of so called "self-certified Linux experts" which believe,
> everything can be handled by using the only tool they know.
The important question is *always*: "what is the threat?" For a lot of
the practical common situations a Linux IPTables firewall will be as
effective as the top notch Checkpoint/CISCO solution because FW-1 and
PIX do offer a better parsing and response code (for example) but in the
end of the day it's upgrading your OpenSSL libraries on time and such
that really counts.
It's not about who is better - it's about who is *enough* to counter the
threat enough to get you to a point where that specific issue isn't the
'weakest link' anymore. I think Linux does that very very well in many
situations.
>
> >Never trust Security Consultants.
>
> BS. Invest money in real consultants that know their trade. They
> simply might not be the cheapest and they might tell you solutions
> that hurt (e.g. training your staff) but of course there are lots of
> people that know what they're talking about.
To this I all heartily agree. Get good people (and be prepared to *pay*
for good people) and then *listen* to them. Sadly, I believe that the
latter seems to be less common then the former... :-(
Gilad
Alan Cox <[email protected]> writes:
>On Thu, 2002-10-24 at 12:09, Henning P. Schmiedehausen wrote:
>> Ville Herva <[email protected]> writes:
>>
>> >the /dev/kmem hole, but this closes 2 classes of attacks - loading rootkit
>> >module and booting with a hacked kernel in straight-forward way.
>>
>> Question: What do I lose when you remove /dev/kmem?
>> Related question: Would it be useful to make /dev/kmem read-only?
>Makes no real difference. If the user got to root they can work the
>chmod command. What you want to do is revoke CAP_SYS_RAWIO which kills
>off all direct hardware access - mem/kmem/iopl/ioperm etc. It does stop
>non kernel fb X working but thats not a big deal on a server.
Hm,
I've been in a hurry when I wrote my first mail. What I meant was:
- I remove drivers/char/mem.c from my kernel. What do I lose? (/dev/null,
/dev/zero and /dev/full afaics but cut this down to "i remove everything
related to mem_fops, kmem_fops and port_fops").
- I remove write_mem(), write_kmem() and write_port() from drivers/char/mem.c
What do I lose?
Removing CAP_SYS_RAWIO is nice, but I actually want to remove the code
from the kernel, not just disabling it (Yes, of course I could try but
my test box is in pieces ATM...).
The pointer to the Xserver is a good one. Thanks.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Thu, 2002-10-24 at 15:40, Henning P. Schmiedehausen wrote:
> Removing CAP_SYS_RAWIO is nice, but I actually want to remove the code
> from the kernel, not just disabling it (Yes, of course I could try but
> my test box is in pieces ATM...).
Just removing /dev/mem isnt enough. You still need CAP_SYS_RAWIO
revoked. There are many raw i/o accessors it covers
On 24 Oct 2002, Tony Gale wrote:
> Date: 24 Oct 2002 11:01:04 +0100
> From: Tony Gale <[email protected]>
> To: [email protected]
> Subject: Re: One for the Security Guru's
>
> On Thu, 2002-10-24 at 10:38, Henning P. Schmiedehausen wrote:
> > Gerhard Mack <[email protected]> writes:
> >
> > >Actually at the place that just went bankrupt on me I had a Security
> > >consultant complain that 2 of my servers were outside the firewall. He
> > >recommended that I get a firewall just for those 2 servers but backed off
> > >when I pointed out that I would need to open all of the same ports that
> > >are open on the server anyways so the vulnerability isn't any less with
> > >the firewall.
> >
> > So you should've bought a more expensive firewall that offers protocol
> > based forwarding instead of being a simple packet filter.
> >
> > packet filter != firewall. That's the main lie behind most of the
> > "Linux based" firewalls.
> >
> > Get the real thing. Checkpoint. PIX. But that's a little
> > more expensive than "xxx firewall based on Linux".
> >
>
> Thats not entirely accurate, or fair. A packet filter is a type of
> Firewall (or can be). A Firewall is a means to implement a security
> policy, usually specifically a network access policy. A Packet Filter,
> including a ""Linux based" firewall" is a perfectly acceptable means of
> achieving that goal, if it meets the policy requirements.
>
> Ref. http://csrc.nist.gov/publications/nistpubs/800-10/ (over 7 years
> old, but still highly relevant).
>
> Most commercial firewalls are very bad at protecting servers offering
> Internet services, they aren't designed to do it.
>
It gets even worse if almost all of your services are encrypted(like you
would find on an e-commerse site). https will blind an IDS. The last
place I worked only had 3 ports open and 2 of them were encrypted.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
Unfortunantly there are things that you can't do with a network based SSL
accelerator box (specificly have your webserver give people an
understandable warning if they are useing weak encryption) so this isn't
the Right (tm) way of doing things, it's one of the ways to do them.
David Lang
On Thu, 24 Oct 2002, Henning P. Schmiedehausen wrote:
> Date: Thu, 24 Oct 2002 16:39:23 +0000 (UTC)
> From: Henning P. Schmiedehausen <[email protected]>
> To: [email protected]
> Newsgroups: hometree.linux.kernel
> Subject: Re: One for the Security Guru's
>
> Gerhard Mack <[email protected]> writes:
>
> >It gets even worse if almost all of your services are encrypted(like you
> >would find on an e-commerse site). https will blind an IDS. The last
> >place I worked only had 3 ports open and 2 of them were encrypted.
>
> Nah. Do it right:
>
> Internet ----- Firewall ---- SSL Accelerator Box --+---- Webserver
> HTTPS HTTPS | HTTP
> |
> IDS
>
> Check out the boxes from SonicWall, they're quite nice. Expensive,
> though. If your E-Commerce site can't afford them, well, then they
> shouldn't be able to affore a security consulant in the first
> place. :-)
>
> Regards
> Henning
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
> D-91054 Buckenhof Fax.: 09131 / 50654-20
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Gerhard Mack <[email protected]> writes:
>It gets even worse if almost all of your services are encrypted(like you
>would find on an e-commerse site). https will blind an IDS. The last
>place I worked only had 3 ports open and 2 of them were encrypted.
Nah. Do it right:
Internet ----- Firewall ---- SSL Accelerator Box --+---- Webserver
HTTPS HTTPS | HTTP
|
IDS
Check out the boxes from SonicWall, they're quite nice. Expensive,
though. If your E-Commerce site can't afford them, well, then they
shouldn't be able to affore a security consulant in the first
place. :-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
Ville Herva <[email protected]> writes:
> On Wed, Oct 23, 2002 at 11:15:14PM +0100, you [James Stevenson] wrote:
> >
> > As to load a module you must be root and if you are root you
> > can read / write disks. Thus you could recompile your own kernel
> > install it try to force a crash or a reboot which is not hard as root
> > and the person may not even notice that the kernel has grown by a few
> > bytes after the crash.
>
> Which is why some people configure kernels not to support installing modules
> and only use read-only media (e.g. CD-R) for booting. Sure, there's still
> the /dev/kmem hole, but this closes 2 classes of attacks - loading rootkit
> module and booting with a hacked kernel in straight-forward way.
>
> BTW, this might be a reason to make kexec syscall to be a config option (if
> it isn't already.)
It already is a config option.
Eric
On Thu, 2002-10-24 at 18:39, Henning P. Schmiedehausen wrote:
> Gerhard Mack <[email protected]> writes:
> >It gets even worse if almost all of your services are encrypted(like you
> >would find on an e-commerse site). https will blind an IDS. The last
> >place I worked only had 3 ports open and 2 of them were encrypted.
>
> Nah. Do it right:
>
> Internet ----- Firewall ---- SSL Accelerator Box --+---- Webserver
> HTTPS HTTPS | HTTP
> |
> IDS
>
Eh... not really:
A. If there's a buffer overflow in the SSL Accelerator box the firewall
wont do you much good (it helps, but only a little).
B. The firewall in this setup provides very little besides packet
filtering anyway.
SO... basically we're back to square one. A better firewall might offer
more features but in the end the end point must be secure or all of
these features wont do a damn good, thus in many cases it would make
sense to use the free (as in both beer and speech) solution provided by
Linux, not because it's the best, but because it's enough: there are
weaker links to worry about.
Gilad.
--
Gilad Ben-Yossef <[email protected]>
http://benyossef.com
"Geeks rock bands cool name #8192: RAID against the machine"
Gee, isn't this a kind of "man in the middle" security breach ?!?! Most
of the people on the net, including me, expect that nobody and I mean
nobody is sitting between my browser and the web server, seeing
unencrypted packets when we use SSL.
And now your telling me that the SSL Accelerator Box and the IDS is
seeing in clear text the traffic I thought only the web server was
seeing ?!?! And presumably, the IDS is logging somewhere all the credit
card info that I might be sending...
Mind you, I guess nothing prevented somebody to do something behind the
Webserver to do some wicked thing but now, your telling me that they are
devices, on the open market, specially design to do this!
So now, you have to worry about "internal" security on 3 boxes instead
of one.
Customer Information Security is now tredeoff for more Servers Security.
How sad :(
Danny
On Thu, 2002-10-24 at 12:39, Henning P. Schmiedehausen wrote:
> Nah. Do it right:
>
> Internet ----- Firewall ---- SSL Accelerator Box --+---- Webserver
> HTTPS HTTPS | HTTP
> |
> IDS
>
> Check out the boxes from SonicWall, they're quite nice. Expensive,
> though. If your E-Commerce site can't afford them, well, then they
> shouldn't be able to affore a security consulant in the first
> place. :-)
>
> Regards
> Henning
At 09:38 AM 10/24/02 +0000, Henning P. Schmiedehausen wrote:
>So you should've bought a more expensive firewall that offers protocol
>based forwarding instead of being a simple packet filter.
>
>packet filter != firewall. That's the main lie behind most of the
>"Linux based" firewalls.
>
>Get the real thing. Checkpoint. PIX. But that's a little
>more expensive than "xxx firewall based on Linux".
OK, I don't advertise that I'm the "know-it-all" when it comes to security,
and in the State of Nevada (USA) I'm not allowed to advertise as a
"security consultant" without a special license from the Private
Investigator's License Board.
I have a firewall running on 2.4.18 (Red Hat 7.3/Valhalla with updates)
which is (on an experimental basis) doing port-number-based forwarding to a
Web server. The idea is that the Web server is *not* directly on the 'Net,
but is instead behind a firewall that steers incoming traffic to it on two
specific ports: 80 and 443. (Yes, I installed the slapper on the Web
server.) This was done using IPTABLES.
I've also been experimenting with the traffic limiting capabilities, as one
co-locate provider offers discounts for guaranteed lower bandwidth
utilization, so by limiting the bandwidth using IPTABLES I should be able
to cut my co-lo costs to 1/3 of what they would be with "unlimited" bandwidth.
I've worked with the PIX, and I don't see what I'm missing in features
between the PIX and Linux/IPTABLES. I'm sure there is something. Please
amplify on your comments.
On Thu, 2002-10-24 at 19:04, Gilad Ben-Yossef wrote:
> On Thu, 2002-10-24 at 18:39, Henning P. Schmiedehausen wrote:
> > Gerhard Mack <[email protected]> writes:
> > >It gets even worse if almost all of your services are encrypted(like you
> > >would find on an e-commerse site). https will blind an IDS. The last
> > >place I worked only had 3 ports open and 2 of them were encrypted.
> >
> > Nah. Do it right:
> >
> > Internet ----- Firewall ---- SSL Accelerator Box --+---- Webserver
> > HTTPS HTTPS | HTTP
> > |
> > IDS
> >
>
> Eh... not really:
>
> A. If there's a buffer overflow in the SSL Accelerator box the firewall
> wont do you much good (it helps, but only a little).
This is a hardware device. Hardware as in "silicon". I very much doubt
that you can run "general purpose programs" on a device specifically
designed to do crypto. And this is _not_ just an "embedded Linux on ix86
with a crypto chip".
> B. The firewall in this setup provides very little besides packet
> filtering anyway.
You're right. But if I'd let it off, I'd would have gotten mail with
"there is no firewall in your setup, it's not secure". Either way I
lose. :-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Fri, 2002-10-25 at 00:02, Danny Lepage wrote:
> Gee, isn't this a kind of "man in the middle" security breach ?!?! Most
> of the people on the net, including me, expect that nobody and I mean
> nobody is sitting between my browser and the web server, seeing
> unencrypted packets when we use SSL.
If you don't control the network between the Accelerator and your
webserver, you're toast anyway.
> And now your telling me that the SSL Accelerator Box and the IDS is
> seeing in clear text the traffic I thought only the web server was
> seeing ?!?! And presumably, the IDS is logging somewhere all the credit
> card info that I might be sending...
So what? How many "secure ecommerce sites" just put the information that
you sent over the secure channel into a database accessible by a tcp
port? or simply print it out? Send it via unencrypted mail to their
sales department (presumable to [email protected]. Yes, I've
already seen that.). HTTPS is just a gurantee, that your data isn't
sniffed between your web browser and the device you're talking to. Once
the data hits the web server, there is nothing that HTTPS can do or you
can rely on.
> Mind you, I guess nothing prevented somebody to do something behind the
> Webserver to do some wicked thing but now, your telling me that they are
> devices, on the open market, specially design to do this!
Of course. Once you hit more than a few https transfers, you can either
burn your cpu cycles for doing crypto or simply use a device.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
Am Don, 2002-10-24 um 11.47 schrieb Henning P. Schmiedehausen:
> Sheesh, some even install a full desktop with "[gnome|kde]-games" on a
> server. What is this? Microsoft Windows <insert your poison here>" ?
Don't laugh; I had such a box reinstalled from ground just the day
before yesterday because I found a RedHat full Install on it. Not to
mention that there're "admins" out there who use GNOME as root on a
fairly busy mailserver <shudder>...
--
Servus,
Daniel
* Stephen Satchell ([email protected]) wrote:
> I've also been experimenting with the traffic limiting capabilities, as one
> co-locate provider offers discounts for guaranteed lower bandwidth
> utilization, so by limiting the bandwidth using IPTABLES I should be able
> to cut my co-lo costs to 1/3 of what they would be with "unlimited"
> bandwidth.
http://www.lartc.org ; When talking about traffic shaping with Linux
you're really talking about tc from the iproute2 package. I'd recommend
you check out that URL if you havn't already and that you strongly
consider using HTB for your traffic shaping needs, it's alot easier to
use and makes alot more sense than CBQ.
> I've worked with the PIX, and I don't see what I'm missing in features
> between the PIX and Linux/IPTABLES. I'm sure there is something. Please
> amplify on your comments.
Eh, it depends on how you look at it, but... The cisco includes support
for checking out high-level protocols, such as HTTP. Basically you can
set things up inside the PIX based on what URL is being requested and
such. That's why the PIX is more than just a packet filter. Personally
I still characterize my Linux box running iptables as a firewall. If
you want to do the same kind of thing the PIX is doing on port 80 you'd
need to run squid or something similar to it and set it up as a reverse
proxy with associated access rules and whatnot. Things like deny
anything with cmd.exe in it, etc.
Stephen
On Fri, Oct 25, 2002 at 02:28:56PM +0200, Daniel Egger wrote:
> > Sheesh, some even install a full desktop with "[gnome|kde]-games" on a
> > server. What is this? Microsoft Windows <insert your poison here>" ?
> Don't laugh; I had such a box reinstalled from ground just the day
> before yesterday because I found a RedHat full Install on it. Not to
> mention that there're "admins" out there who use GNOME as root on a
> fairly busy mailserver <shudder>...
Pity they never read lkml, nor any literature at all.
At 02:28 PM 10/25/02 +0200, Daniel Egger wrote:
>Don't laugh; I had such a box reinstalled from ground just the day
>before yesterday because I found a RedHat full Install on it. Not to
>mention that there're "admins" out there who use GNOME as root on a
>fairly busy mailserver <shudder>...
I'm not laughing, I inherited a firewall box that had a full install of Red
Hat 7.1, complete with GUI. I got the network information, loaded up 7.3
with minimal installation, and cleaned up that "minimal install" by using
"rpm -qa" (it's your friend) to identify and rid the system of every single
package not necessary to the operation of a firewall.
GCC. PERL. Sendmail (!). The eight different version of FTP. (I may be
exaggerating, but the stream of packages that offer FTP client and server
services seems to be endless.) Things that a root kit would find extremely
useful to install back doors and other nasties. Debuggers. Those were
just the extra packages -- I also scanned for unnecessary SUID binaries
when I was finished and blasted them to the ol' game grid.
I then used IPTABLES to implement the security policy of the client, and
part of that policy was that the only packets that were allowed to talk
directly to the firewall was SSH, and only from my range of IP addresses,
and ping from anywhere...and I rate-limited the ping to 10 per second so
that a ping flood would not hose the return channel.
Incoming SYN requests to the firewall (except for SSH directed to the
firewall) are alway dropped silently, and the vast majority of UDP packets
also find their way to the bit bucket. Oddball TCP attacks (the log showed
a LAMP-TEST packet attack last week) are also given the heave-ho. I have
NAT in the outgoing direction, and only those ports necessary to the
operation of the client are open. That means no ICQ, at all, for
example. No streaming audio. And, as you can guess, no outbound
connections are accessible to the likes of BackOrfice.
I'm sure there is a hole somewhere in that firewall box, but I have plugged
all the ones I found documented on CERT.
Oh, and a low-volume Web server was moved off the firewall and onto a
separate box, with the firewall forwarding packet traffic via IPTABLES rules.
Followup to: <1035539042.23977.24.camel@forge>
By author: Henning Schmiedehausen <[email protected]>
In newsgroup: linux.dev.kernel
> >
> > A. If there's a buffer overflow in the SSL Accelerator box the firewall
> > wont do you much good (it helps, but only a little).
>
> This is a hardware device. Hardware as in "silicon". I very much doubt
> that you can run "general purpose programs" on a device specifically
> designed to do crypto. And this is _not_ just an "embedded Linux on ix86
> with a crypto chip".
>
Hardware devices have bugs, too. Furthermore, most devices marketed
as "hardware" still have programmable stuff underneath. Trust me.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Thu, Oct 24, 2002 at 09:38:46AM +0000, Henning P. Schmiedehausen wrote:
> Get the real thing. Checkpoint. PIX. But that's a little
> more expensive than "xxx firewall based on Linux".
PIX? Is that the one that breaks TCP/IP when an ACK is lost on
the side that the data is coming from?
Roger
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
"H. Peter Anvin" <[email protected]> writes:
>Followup to: <1035539042.23977.24.camel@forge>
>By author: Henning Schmiedehausen <[email protected]>
>In newsgroup: linux.dev.kernel
>> >
>> > A. If there's a buffer overflow in the SSL Accelerator box the firewall
>> > wont do you much good (it helps, but only a little).
>>
>> This is a hardware device. Hardware as in "silicon". I very much doubt
>> that you can run "general purpose programs" on a device specifically
>> designed to do crypto. And this is _not_ just an "embedded Linux on ix86
>> with a crypto chip".
>>
>Hardware devices have bugs, too. Furthermore, most devices marketed
>as "hardware" still have programmable stuff underneath. Trust me.
Of course they have. I'm not that dumb. :-) I won't expect any piece
of silicon speak http, snmp and have configureable ip adresses without
any programming. I do had my share of Cisco router fun.... :-)
But my point is, that these beasts normally don't run a general
purpose operating system and that they're much less prone to buffer
overflow or similar attacks, simply because they don't use popular
software with known bugs (e.g. OpenSSL) or these functions (like
doing crypto) are in hardware.
If you have a processor that sets up an ASIC to do "insert https here,
use this key, remove http there", you might be able to attack the IP
stack running on the processor which gets the packets from the wire
and puts them back onto the wire. But you won't be able to trick any
bug or overflow in the crypto routines into opening a root shell on
the ASIC. :-)
Especially if there is no such thing as a /bin/sh binary on the
bugger. And even if you _do_; you still only have a shell on the
accelerator. Not on the application server.
If you ask me "how can you trust such a device if you can't look at
the source; well, I don't have to. I can tell the customer "this
device has been approved by <insert your certification authority here>
and you pay gobs of cash for simply having this certified device".
Replace "device" with "certificate" and you have the same thing as
getting your web server key certification from Verisign or Thawte.
You pay money and get a "trusted device".
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Fri, Oct 25, 2002 at 09:47:23AM -0400, Stephen Frost wrote:
> Eh, it depends on how you look at it, but... The cisco includes support
> for checking out high-level protocols, such as HTTP. Basically you can
So, your PIX is looking at the HTTP requests, and it is validating
them. Fine. Now what is the largest HTTP request that you're going
to allow? 1k? 10k? 100k?
The PIX is NOT filtering the size of the HTTP request. It will happily
allow a multimegabyte request to come through. Is that exploiting a bug
in your http server? You don't know. And the PIX doesn't help.
When I encountered a PIX, multimegabyte HTTP requests were valid, and
the PIX screwed them up. A slight thinko on the side of the PIX
programmers.
The PIX HTTP filtering may give you some extra controls (I hear you can
do URL based filtering.... Wow!). Don't you have that control on your
webserver?
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
Rogier Wolff <[email protected]> writes:
>On Thu, Oct 24, 2002 at 09:38:46AM +0000, Henning P. Schmiedehausen wrote:
>> Get the real thing. Checkpoint. PIX. But that's a little
>> more expensive than "xxx firewall based on Linux".
>PIX? Is that the one that breaks TCP/IP when an ACK is lost on
>the side that the data is coming from?
Depends on your PIX OS. As with any other OS, there are bugs and you
should monitor the vendor mailing lists for updates and fixes.
It did broke SACK once. There was an update and the problem was
solved. Thats what a vendor is for.
Regards
Henning
What did you think? That I fall bait to this troll? :-)
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Thu, Oct 24, 2002 at 09:47:38AM +0000, Henning P. Schmiedehausen wrote:
> James Stevenson <[email protected]> writes:
>
> >can read / write disks. Thus you could recompile your own kernel
>
> Don't put a compiler on the box.
Don't you have a compiler at home? I do.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
On Sat, Oct 26, 2002 at 10:43:29AM +0000, Henning P. Schmiedehausen wrote:
> But my point is, that these beasts normally don't run a general
> purpose operating system and that they're much less prone to buffer
> overflow or similar attacks, simply because they don't use popular
> software with known bugs (e.g. OpenSSL) or these functions (like
> doing crypto) are in hardware.
The script kiddies simply haven't bothered to attack these boxes yet.
When they are done with the bugs in the common oses, they will move on
to other targets...
And you say that a "root shell" on the box doesn't give you root on
the application server? It might be too hard for a "worm" but it will
be easy for a human.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
On Sat, Oct 26, 2002 at 10:43:29AM +0000, Henning P. Schmiedehausen
wrote:
> But my point is, that these beasts normally don't run a general
> purpose operating system and that they're much less prone to buffer
> overflow or similar attacks, simply because they don't use popular
> software with known bugs (e.g. OpenSSL) or these functions (like
> doing crypto) are in hardware.
As someone who has worked on a couple of these which are presently on
the market I can assure you that many of these things have plenty of
'popular software' in them... albeit hacked up and mangled to bits at
times... but it's there, and often vulnerable to many of the same
problems you would have under Linux/Apache/whatever.
--cw
James Cleverdon <[email protected]> writes:
> Be surprised: I run "gpg --verify foo.tgz.sign foo.tgz" every time I download
> from kernel.org. And, "rpm --checksig *.rpm" on stuff from redhat.com too.
>
> Given the recent trojaned source packages, I recommend that everyone do the
> same.
Aren't the signatures on kernel.org automatically generated?
--
Florian Weimer [email protected]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898