Compiler security issues ...

[dbeezzz]

What exactly are the security issues with regards to leaving a compiler on my system ? I'm installing an rpm of gcc at the moment. And I'm wondering what I should do with it when I'm finished. Does a

chown root
chmod 700

... suffice ? Can't the intruder at user level just download and install their own gcc once they get onto the system ? If so, then why does it matter ?

Also, how come I was able to install an rpm on the system without a compiler. I thought that the rpm process would need to compile code, no ?

 

[zeland]

1. Both root and regular users can compile programs, but only root can install files to system folders. i.e. /usr/bin, /sbin etc. So even if an intruder at user level compiles his own program, but he can't install it anywhere where somebody else will use it.

2. There are 2 types of RPMs. A regular RPM <some_package>.rpm, contains precompiled binaries that are ready to use. A source RPM <some_package>.src.rpm, contains a program's source code that will be "built" into a regular RPM with a compiler


--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[dbeezzz]

Thanks zealand,

But in response to your first question. Wouldn't a regular user be able to exchange his compiled program with an suid program, and thus run as root ?

I had heard that leaving a compiler on your system was a bad idea. But it really doesn't seem to matter much if an intruder can just download and then use his own ?

 

[zeland]

If I'm not mistaken, suid means to run the program as the owner and not as root. So, if I am user hacker and chmod +s some_file, anybody who runs this program will run it as hacker and not root. I tried to chown some files to belong to root but the system doesn't allow it.

I'm not too sure if having a compiler on your system is a bad idea or not. I use a lot of software that I compile from source on a regular basis and can't imagine how can a person live with a compiler.


--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[dbeezzz]

yes, but I think it may be possible to copy over a root suid program with a hacker program and then run it as root.

Also, the more likely possibility I'd imagine is that if the attacker can place his program ahead of the root suid program in PATH. And then have the system run his.

I'm not sure if this would work or not, but I think there might be something in bastille about it.

 

[lgarner]

You're correct, but the file permissions should prohibit this.

When I execute "echo $PATH", the key parts are:
/usr/local/bin:/bin:/usr/bin:...:/home/me/bin

The first three directories are owned by root:root and have 755 permissions. So, ordinary users can't add or modify files in there.

If your system gets "rooted", then all bets are off. There's little protection against that, so you add things like external logging, bastille, selinux, file scans (tripwire, osiris), and so forth. If someone gets in as "root", there's nothing they can't do. Leaving a compiler on the system is the least of your worries.

 

[SamBones]

I believe the idea behind not having a compiler on a secure production system is that if someone has broken into your system, you want to make it as hard as possible for him/her to do anything. If you remove all functionality that's not needed to run the application being served by that machine, then you make it difficult for the intruder to do anything. A compiler is just another tool that doesn't need to be there to run the production application.

And you are right that they may be able to download a compiler. Just removing the compiler is no security by itself. It is intended to be one step in a long list of things you do to harden a machine.

And hardening goes beyond just the server itself. If the machine is JUST a web server and it is Internet facing, then the firewall should NOT allow FTP or SFTP to the server. Things like that work together with other steps to make your systems more secure.

Here's a document on hardening a Solaris 8 System. This is a good example of locking down a system so it is more secure. Notice the long list of things being disabled. Every one of those is to make it harder on someone that might have broken into your system.

There's also another reason to remove a compiler that has nothing to do with "hackers". In a corporate environment, if a compiler is on a production system, that may allow a programmer or support person to make "ad-hoc" changes to the application. These would be changes that aren't tested and may have nasty intentions (i.e. stealing a fraction of a cent from every transaction). It's better to have your compiler only be on development machines and not on UAT, QA, Staging, and Production machine (or how ever many environments you have).

Hope this helps.

 

[thedaver]

I like to recommend the hardening materials from

http://www.openna.com/

They are really good, in their book, at explaining hardening strategies on a multitude of key areas.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/