Writes to mounted devices containing file-systems.

Writes to mounted devices containing file-systems.

[Richard B. Johnson]

Is it possible that Linux could decline to write to a device that
contains mounted file-systems? OTW, don't allow raw writes to
devices or partitions if they are mounted; writes could only
be through the file-systems themselves.

One of my file-servers was destroyed by an in-house hacker,
(consultant) rented by our alleged Chief Information Officer,
to destroy Linux systems and thereby show that they can't
be used in a "professional" environment.

I have about 20 megabytes of logs showing the machine being
attacked from inside our firewall. Each time an attack occurred,
I would firewall-out its phony IP address (ipchains). A few hours
later the cycle repeated with another phony IP address.

The exploit used multiple calls to get the system time, followed
by an attempt to mount a file-system. Apparently the exploit
eventually works because the system went down and the result was
that the root file-system device, /dev/sda, was completely written
with:

	"S E C U R I T Y "

8 Gb written with this 16-bytes pattern.

This server is very important to my work and it took a long time
to get it back up. The attacks continue. Today they are using some
sendmail exploit:


Aug 10 07:56:02 quark sendmail[66]: rejecting connections on daemon MTA:
load average: 115
Aug 10 07:56:02 quark sendmail[66]: rejecting connections on daemon MSA: load average: 115
Aug 10 07:56:17 quark sendmail[66]: rejecting connections on daemon MTA: load average: 115
Aug 10 07:56:17 quark sendmail[66]: rejecting connections on daemon MSA: load average: 115
Aug 10 07:56:32 quark sendmail[66]: rejecting connections on daemon MTA: load average: 105
Aug 10 07:56:32 quark sendmail[66]: rejecting connections on daemon MSA: load average: 105
Aug 10 07:56:47 quark sendmail[66]: rejecting connections on daemon MTA: load average: 87
Aug 10 07:56:47 quark sendmail[66]: rejecting connections on daemon MSA: load average: 87
Aug 10 07:57:02 quark sendmail[66]: rejecting connections on daemon MTA: load average: 68
Aug 10 07:57:02 quark sendmail[66]: rejecting connections on daemon MSA: load average: 68
Aug 10 07:57:17 quark sendmail[66]: rejecting connections on daemon MTA: load average: 53
Aug 10 07:57:17 quark sendmail[66]: rejecting connections on daemon MSA: load average: 53
Aug 10 07:57:32 quark sendmail[66]: rejecting connections on daemon MTA: load average: 41
Aug 10 07:57:32 quark sendmail[66]: rejecting connections on daemon MSA: load average: 41
Aug 10 07:57:47 quark sendmail[66]: rejecting connections on daemon MTA: load average: 32
Aug 10 07:57:47 quark sendmail[66]: rejecting connections on daemon MSA: load average: 32
Aug 10 07:58:02 quark sendmail[66]: rejecting connections on daemon MTA: load average: 25
Aug 10 07:58:02 quark sendmail[66]: rejecting connections on daemon MSA: load average: 25
Aug 10 07:58:17 quark sendmail[66]: rejecting connections on daemon MTA: load average: 19
Aug 10 07:58:17 quark sendmail[66]: rejecting connections on daemon MSA: load average: 19
Aug 10 07:58:32 quark sendmail[66]: rejecting connections on daemon MTA: load average: 15
Aug 10 07:58:32 quark sendmail[66]: rejecting connections on daemon MSA: load average: 15
Aug 10 07:58:47 quark sendmail[66]: rejecting connections on daemon MTA: load average: 12
Aug 10 07:58:47 quark sendmail[66]: rejecting connections on daemon MSA: load average: 12
Aug 10 07:59:02 quark sendmail[66]: accepting connections again for daemon MTA
Aug 10 07:59:02 quark sendmail[66]: accepting connections again for daemon MSA
Aug 10 08:00:29 quark syslog: callit: (150001) cannot fork: Try again
Aug 10 08:01:03 quark sendmail[66]: rejecting connections on daemon MTA: load average: 239
Aug 10 08:01:03 quark sendmail[66]: rejecting connections on daemon MSA: load average: 239
Aug 10 08:01:18 quark sendmail[66]: rejecting connections on daemon MTA: load average: 267
Aug 10 08:01:18 quark sendmail[66]: rejecting connections on daemon MSA: load average: 267
Aug 10 08:01:33 quark sendmail[66]: rejecting connections on daemon MTA: load average: 278
Aug 10 08:01:33 quark sendmail[66]: rejecting connections on daemon MSA: load average: 278
Aug 10 08:01:48 quark sendmail[66]: rejecting connections on daemon MTA: load average: 276
Aug 10 08:01:48 quark sendmail[66]: rejecting connections on daemon MSA: load average: 276
Aug 10 08:02:03 quark sendmail[66]: rejecting connections on daemon MTA: load average: 264
Aug 10 08:02:03 quark sendmail[66]: rejecting connections on daemon MSA: load average: 264
Aug 10 08:02:18 quark sendmail[66]: rejecting connections on daemon MTA: load average: 245
Aug 10 08:02:18 quark sendmail[66]: rejecting connections on daemon MSA: load average: 245
Aug 10 08:02:33 quark sendmail[66]: rejecting connections on daemon MTA: load average: 219
Aug 10 08:02:33 quark sendmail[66]: rejecting connections on daemon MSA: load average: 219
Aug 10 08:02:48 quark sendmail[66]: rejecting connections on daemon MTA: load average: 187
Aug 10 08:02:48 quark sendmail[66]: rejecting connections on daemon MSA: load average: 187
Aug 10 08:03:03 quark sendmail[66]: rejecting connections on daemon MTA: load average: 153
Aug 10 08:03:03 quark sendmail[66]: rejecting connections on daemon MSA: load average: 153
Aug 10 08:03:18 quark sendmail[66]: rejecting connections on daemon MTA: load average: 119
Aug 10 08:03:18 quark sendmail[66]: rejecting connections on daemon MSA: load average: 119
Aug 10 08:03:24 quark in.rlogind[13609]: connect from chaos.analogic.com
Aug 10 08:03:33 quark sendmail[66]: rejecting connections on daemon MTA: load average: 93
Aug 10 08:03:33 quark sendmail[66]: rejecting connections on daemon MSA: load average: 93
Aug 10 08:03:40 quark su: johnson on /dev/ttyp0
Aug 10 08:03:48 quark sendmail[66]: rejecting connections on daemon MTA: load average: 72
Aug 10 08:03:48 quark sendmail[66]: rejecting connections on daemon MSA: load average: 72
Aug 10 08:04:03 quark sendmail[66]: rejecting connections on daemon MTA: load average: 56
Aug 10 08:04:03 quark sendmail[66]: rejecting connections on daemon MSA: load average: 56
Aug 10 08:04:18 quark sendmail[66]: rejecting connections on daemon MTA: load average: 44
Aug 10 08:04:18 quark sendmail[66]: rejecting connections on daemon MSA: load average: 44
Aug 10 08:04:33 quark sendmail[66]: rejecting connections on daemon MTA: load average: 34
Aug 10 08:04:33 quark sendmail[66]: rejecting connections on daemon MSA: load average: 34
Aug 10 08:04:48 quark sendmail[66]: rejecting connections on daemon MTA: load average: 27
Aug 10 08:04:48 quark sendmail[66]: rejecting connections on daemon MSA: load average: 27
Aug 10 08:05:03 quark sendmail[66]: rejecting connections on daemon MTA: load average: 21
Aug 10 08:05:03 quark sendmail[66]: rejecting connections on daemon MSA: load average: 21
Aug 10 08:05:18 quark sendmail[66]: rejecting connections on daemon MTA: load average: 16
Aug 10 08:05:18 quark sendmail[66]: rejecting connections on daemon MSA: load average: 16
Aug 10 08:05:33 quark sendmail[66]: rejecting connections on daemon MTA: load average: 13
Aug 10 08:05:33 quark sendmail[66]: rejecting connections on daemon MSA: load average: 13
Aug 10 08:05:48 quark sendmail[66]: accepting connections again for daemon MTA
Aug 10 08:05:48 quark sendmail[66]: accepting connections again for daemon MSA


Microsoft FUD has convinced a lot of companies that they will
be subjected to stockholder lawsuits and customer rejection if
they use Linux or any of those "insecure" Unix-type machines.

In this company, they hired a "CIO" who thinks that no computers
should have any local storage or boot capability. They must all
boot from some secure (M$) file-server. They will not be allowed
to have local disks and, horrors -- of course no floppy drives or
CD-ROMS.

He doesn't care that we are in the business of making software-driven
machines so we require access to the guts of computers and their
operating systems.

Linux development needs to know about the "big lie" method of
forcing everybody to use what big companies (or the government)
want you to use. Think, for a minute, about what "everybody knows".

"Everybody knows" relates to something that is so commonly accepted
that nobody bothers to check if it's true or not.

Everybody knows:
	"global warming..."
	"greenhouse gasses..."
	"asbestos as a carcinogin..."
	"etc..."

The next one will be:

	"Linux is insecure..."

So, if it is at all possible to help improve its security without
hurting its performance very much, it's really a matter of life-or-
death for Linux. Otherwise "they" will get us.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Writes to mounted devices containing file-systems.

[Alan Cox]

> Aug 10 08:05:18 quark sendmail[66]: rejecting connections on daemon MTA: load average: 16
> Aug 10 08:05:18 quark sendmail[66]: rejecting connections on daemon MSA: load average: 16
> Aug 10 08:05:33 quark sendmail[66]: rejecting connections on daemon MTA: load average: 13
> Aug 10 08:05:33 quark sendmail[66]: rejecting connections on daemon MSA: load average: 13
> Aug 10 08:05:48 quark sendmail[66]: accepting connections again for daemon MTA

Thats your mailer laughing at someones pitiful attempt to knock it over. 
Sendmail does load protection. Anyone with effectively equivalent or better
bandwidth can always DoS a system. Ask yahoo.

> In this company, they hired a "CIO" who thinks that no computers
> should have any local storage or boot capability. They must all
> boot from some secure (M$) file-server. They will not be allowed
> to have local disks and, horrors -- of course no floppy drives or
> CD-ROMS.

Good policy (well maybe not the choice of fileserver OS) in many
environments. How do you think McDonalds unix based tills run 8) - no
floppy believe me.

> He doesn't care that we are in the business of making software-driven
> machines so we require access to the guts of computers and their
> operating systems.

Smart people migrate, company or division goes out of business, another large
company eventually buys small company that the people who left formed
repeat cycle. 

> So, if it is at all possible to help improve its security without
> hurting its performance very much, it's really a matter of life-or-
> death for Linux. Otherwise "they" will get us.

I think not. Look at the fate of companies whose bosses adopted X.400
because TCP/IP was "some crazy hacker thing" "not industry strength" "had no
telco support" "couldnt provide the needed QoS" ...

Alan

Re: Writes to mounted devices containing file-systems.

[Helge Hafting]

"Richard B. Johnson" wrote:
> 
> Is it possible that Linux could decline to write to a device that
> contains mounted file-systems? OTW, don't allow raw writes to
> devices or partitions if they are mounted; writes could only
> be through the file-systems themselves.
> 
> One of my file-servers was destroyed by an in-house hacker,
> (consultant) rented by our alleged Chief Information Officer,
> to destroy Linux systems and thereby show that they can't
> be used in a "professional" environment.
[...]
> I have about 20 megabytes of logs showing the machine being
> attacked from inside our firewall.

If doing that sort of thing to a server (as opposed to some
poor test machine) is okay in your company... well consider 
"testing" the security on *all* the non-linux machines as well.  

There are so many exploits out there, including but not limited
to those funny email viruses - and you get to run them
from within the firewall!

[...]
> Microsoft FUD has convinced a lot of companies that they will
> be subjected to stockholder lawsuits and customer rejection if
> they use Linux or any of those "insecure" Unix-type machines.
> 
> In this company, they hired a "CIO" who thinks that no computers
> should have any local storage or boot capability. They must all
> boot from some secure (M$) file-server. They will not be allowed
> to have local disks and, horrors -- of course no floppy drives or
> CD-ROMS.
> 
> He doesn't care that we are in the business of making software-driven
> machines so we require access to the guts of computers and their
> operating systems.

Looks like this business is going to fail soon enough...  
Start looking for other employment - avoid the rush when
it collapses.

> Linux development needs to know about the "big lie" method of
> forcing everybody to use what big companies (or the government)
> want you to use. Think, for a minute, about what "everybody knows".
> 
> "Everybody knows" relates to something that is so commonly accepted
> that nobody bothers to check if it's true or not.
> 
> Everybody knows:
>         "global warming..."
>         "greenhouse gasses..."
>         "asbestos as a carcinogin..."
>         "etc..."
> 
> The next one will be:
> 
>         "Linux is insecure..."
> 
> So, if it is at all possible to help improve its security without
> hurting its performance very much, it's really a matter of life-or-
> death for Linux. Otherwise "they" will get us.

Now, if you want a safe machine in such a hostile environment,
consider using a read-only boot device.  I.e. a cdrom, or
a harddisk jumpered read-only after the initial configuration.
You can then boot fast, and have work files on their secure server.

Helge Hafting

Re: Writes to mounted devices containing file-systems.

[Anton Altaparmakov]

On Fri, 10 Aug 2001, Richard B. Johnson wrote:
> Is it possible that Linux could decline to write to a device that
> contains mounted file-systems? OTW, don't allow raw writes to
> devices or partitions if they are mounted; writes could only
> be through the file-systems themselves.

Policy is not something we want in the kernel. Detection and prevention of
writing happens in programs trying to write. E.g. mkntfs will detect that
a partition you are trying to format is mounted and refuse to write to it;
but it provides a "force" switch if you really wanted to do it... I can
think of situations where I really want to write to a mounted fs
(admittedly they not standard use but still I might want to do it).

Anyway, the kernel could never provide you with ultimate security without
sacrificing all functionality. Once they get in, they will get root and
once they have root you have lost, you need to have a system without a
root user and with nobody having capabilities to do things like load
modules, etc... There are so many local exploits that you would lose
for sure. If the attacker cannot write to raw device, he will unmount and
then write to it or he will load a module to send commands to your HD at
ATAPI or SCSI level and kill your hd that way...

[snip destruction of your data]

Why don't you increase security on your machine? - For example do you
really need to run sendmail listenting on port 25? Systems seem to run
quite happily without sendmail listening. All internal use happens
through direct invokation of sendmail binary but YMMV. At least does it
have to listen to anything other than 127.0.0.1?

[snip a lot of horror story about company]

As others have suggested already, it sounds like you want to start looking
for alternative employment...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: Writes to mounted devices containing file-systems.

[Matt]

Anton Altaparmakov mentioned the following:

| Anyway, the kernel could never provide you with ultimate security without
| sacrificing all functionality. Once they get in, they will get root and
| once they have root you have lost, you need to have a system without a
| root user and with nobody having capabilities to do things like load
| modules, etc... There are so many local exploits that you would lose
| for sure. If the attacker cannot write to raw device, he will unmount and
| then write to it or he will load a module to send commands to your HD at
| ATAPI or SCSI level and kill your hd that way...

Couldn't you run something like LIDS? This can be used to lock permissions
down so that root can't unmount filesystems, write to raw devices, etc.

Matt

Writes to mounted devices containing file-systems.

[Steve VanDevender]

Richard B. Johnson writes:
 > 	"Linux is insecure..."

In today's world of Code Red and Sircam, anyone who still believes
Windows is more secure than UNIX or Linux is beyond saving.

Re: Writes to mounted devices containing file-systems.

[Alexander Viro]

On Fri, 10 Aug 2001, Richard B. Johnson wrote:

> One of my file-servers was destroyed by an in-house hacker,
> (consultant) rented by our alleged Chief Information Officer,
> to destroy Linux systems and thereby show that they can't
> be used in a "professional" environment.

Adminned by clueless luser? I have to agree.

> I have about 20 megabytes of logs showing the machine being
> attacked from inside our firewall. Each time an attack occurred,
> I would firewall-out its phony IP address (ipchains). A few hours
> later the cycle repeated with another phony IP address.

Instead of trying to see WTF was going on and fixing the problem instead
of symptoms? _Real_ smart... Or, at least, block everything except the boxen
that have any business accessing it? You know, with explicit "accept" rules
in the beginning of the chain with catch-all "reject" after them...

> The exploit used multiple calls to get the system time, followed
> by an attempt to mount a file-system. Apparently the exploit
> eventually works because the system went down and the result was
> that the root file-system device, /dev/sda, was completely written
> with:
> 
> 	"S E C U R I T Y "
> 
> 8 Gb written with this 16-bytes pattern.

Secure your box and stop whining.  If attacker can gain root on a box
you admin - it's your bloody responsibility to fix the thing, firewalls
or not. Sheesh...

Re: Writes to mounted devices containing file-systems.

[H. Peter Anvin]

Followup to:  <Pine.LNX.3.95.1010810075750.10479A-100000@chaos.analogic.com>
By author:    "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
> 
> In this company, they hired a "CIO" who thinks that no computers
> should have any local storage or boot capability. They must all
> boot from some secure (M$) file-server. They will not be allowed
> to have local disks and, horrors -- of course no floppy drives or
> CD-ROMS.
> 

This is actually a lot easier to do in Linux (using PXELINUX and
NFSroot) -- M$ thinks of this as a threat to their licensing
(fleecing) model.

Seriously, you should use this as an inroad -- central control setups
is something Unix absolutely excels at, and Windows does hideously
poorly.

> He doesn't care that we are in the business of making software-driven
> machines so we require access to the guts of computers and their
> operating systems.

Test machines obviously can't be done this way, but they shouldn't
contain important data.  (And don't expect great performance, either,
although with modern file servers and networks it can be better than
you'd think.)

> The next one will be:
> 
> 	"Linux is insecure..."

Consider SirCam and Code Red an "education campaign" for the
clueless.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Writes to mounted devices containing file-systems.

[Kai Henningsen]

viro@math.psu.edu (Alexander Viro)  wrote on 10.08.01 in <Pine.GSO.4.21.0108101503250.28666-100000@weyl.math.psu.edu>:

> On Fri, 10 Aug 2001, Richard B. Johnson wrote:

> > I have about 20 megabytes of logs showing the machine being
> > attacked from inside our firewall. Each time an attack occurred,
> > I would firewall-out its phony IP address (ipchains). A few hours
> > later the cycle repeated with another phony IP address.
>
> Instead of trying to see WTF was going on and fixing the problem instead
> of symptoms? _Real_ smart... Or, at least, block everything except the boxen
> that have any business accessing it? You know, with explicit "accept" rules
> in the beginning of the chain with catch-all "reject" after them...

Or at least use something like portsentry. Suspicious packets? Block  
first, ask questions later.

MfG Kai

Re: Writes to mounted devices containing file-systems.

[Adrian Bridgett]

On Fri, Aug 10, 2001 at 08:43:58 -0400 (+0000), Richard B. Johnson wrote:
> 
> Is it possible that Linux could decline to write to a device that
> contains mounted file-systems? OTW, don't allow raw writes to
> devices or partitions if they are mounted; writes could only
> be through the file-systems themselves.
[snip]

Personally I'd prefer AIX's approach - let the write through (if the user
wants to shoot themselves in the foot...), but report an error about it (to
syslog). 

Adrian

Email: adrian.bridgett@iname.com
Windows NT - Unix in beta-testing. GPG/PGP keys available on public key servers
Debian GNU/Linux  -*-  By professionals for professionals  -*-  www.debian.org

Re: Writes to mounted devices containing file-systems.

[H. Peter Anvin]

Followup to:  <20010811144729.B31614@wyvern>
By author:    Adrian Bridgett <adrian.bridgett@iname.com>
In newsgroup: linux.dev.kernel
> 
> Personally I'd prefer AIX's approach - let the write through (if the user
> wants to shoot themselves in the foot...), but report an error about it (to
> syslog). 
> 

I don't see any point in having "you just fscked yourself" written to
the syslog.  At the same time, writing to a mounted device is actually
useful: it's currently the only way to write the boot block on an
ext2 filesystem (and Viro: if you start using the page cache for the
superblock in ext2, you probably have to add an explicit interface to
write the boot block at the same time!!!)

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>