FreeBSD security - compilers

General questions about the FreeBSD operating system. Ask here if your question does not fit elsewhere.

FreeBSD security - compilers

Postby chavez243ca » 24 Feb 2011, 17:11

Unix best practices WRT security often mention removing compilers, esp. from systems that sit in a DMZ. What is the FreeBSD community's stance on this? I do most of my package management with the ports system, removing compilers would significantly alter the way I manage the hosts.

How about chmod 700 things like gcc? Would that increase the overall security posture without breaking anything?

Thoughts?
chavez243ca
Member
 
Posts: 106
Joined: 17 Mar 2009, 12:25
Location: Ontario, Canada

Postby xibo » 24 Feb 2011, 17:35

A compiler is not a security threat - at the point where an intruder can make use of a compiler virtually all was lost long ago.
xibo
Member
 
Posts: 373
Joined: 03 Dec 2010, 07:49
Location: Germany

Postby chavez243ca » 24 Feb 2011, 19:00

I think the line of thought is that a compiler aids in the establishment of a rootkit.

From what I have see some of the old tactics would be to gain access to the system, even with limited privs, upload rootkit.c to something like /tmp and compile into the kernel
chavez243ca
Member
 
Posts: 106
Joined: 17 Mar 2009, 12:25
Location: Ontario, Canada

Postby SirDice » 25 Feb 2011, 07:40

The trick is to do the building on a different machine and create packages. Then you can transfer the packages to the 'hardened' machine.

From a security standpoint it's best to remove any compilers from production machines.
Senior UNIX Engineer at Unix Support Nederland
Experience is something you don't get until just after you need it.
User avatar
SirDice
Old Fart
 
Posts: 16166
Joined: 17 Nov 2008, 16:50
Location: Rotterdam, Netherlands

Postby xibo » 25 Feb 2011, 10:32

I was just quoting from OpenBSD's FAQ (section 4.7 subsection "I don't want to install the compilers"), which seems quite reasonable to me.
xibo
Member
 
Posts: 373
Joined: 03 Dec 2010, 07:49
Location: Germany

Postby danbi » 25 Feb 2011, 10:57

The point to remove compilers is that, on a relatively unique OS, one needs to only transfer portable source and have whatever software. Mostly useful on proprietary systems.

FreeBSD, being so popular, does not benefit much from removing compilers. Anyone can download any version of FreeBSD and compile whatever they want on their own desktop computer or easier yet, in a VM.
danbi
Member
 
Posts: 227
Joined: 25 Apr 2010, 09:32
Location: Varna, Bulgaria

Postby mk » 25 Feb 2011, 11:55

danbi you got that one wrong. This as with jails - you put in jail only what you need to run your services. The difference is that is not a jail rather real machine. By removing infrastructure like compilers you limit the attacker by not letting him to use your system against itself. Even better - if it have fast cpu then why not compile world+dog on it. Removing commands is even further extension of this. Using [file]src.conf[/file] you can easily control the process.
mk
Member
 
Posts: 300
Joined: 27 Nov 2008, 13:06

Postby DutchDaemon » 25 Feb 2011, 19:43

All danbi is saying is that an attacker who does have access can simply upload the pre-compiled program, instead of compiling it on the attacked system. All the attacker needs is the same FreeBSD version, including compilers, on their own machine/VM.
User avatar
DutchDaemon
Old Fart
 
Posts: 10463
Joined: 16 Nov 2008, 20:17
Location: The Netherlands

Postby qsecofr » 25 Feb 2011, 22:53

Maybe from a development methodology or procedural standpoint you wouldn't want to compile in a production environment. Development, SQ, and production environments may all be logically & physically separated. Ideally, the objects in production are the same as those tested in SQ, and there are no production object/source mismatches. Differences in environment could affect a build such that the object in production doesn't run as intended. This comment is not specifically pertaining to a DMZ, but more generally. All threats are not always malicious. Non-malicious programming bugs can be just as much a threat, or more even.
qsecofr
Member
 
Posts: 213
Joined: 16 Mar 2009, 04:07
Location: PDX

Postby danbi » 26 Feb 2011, 13:20

Certainly, I agree with qsecofr. However the original question was whether presence of compilers would present security risk. I still stand the opinion, that the lack of compilers cannot stop an determined attacker in any way. Proper security measures and more importantly, processes can.

From my own experience:

In the days of BSD/OS, I had a (large) number of machines, that were specifically configured without any build tools. The primary reason was of course resource preservation, but at the time I did feel safer that way. I also happen to have pet hacker. That person had as the goal of their life to break into some of my machines.
As he was quite persistent, that gave me the perfect opportunity to observe and study this behavior :)
As BSD/OS was commercial software it was not available for download, yet it was enough widespread. That prompted my hacker to go research for an available BSD/OS computer, break in there and have access to the compiler (and libraries). He was then lucky to live until the telnet buffer overflow bug happened and could successfully gain root access to one of my machines. Well.. he didn't know I don't use telnet to access there, nor any of the methods he envisioned to trojan -- and my sync process distributed patched binaries -- yet, the hacker had their 15 minute victory. So, not having compilers did not help at all. Proactive monitoring and management did. It would have been nightmare to patch that number of system that fast manually...

Later attacks, most of them were using interpreted code. So again, no need to have an compiler online. They were unsucessful for other reasons anyway.

Quality control is however completely different thing. My observation unfortunately indicates, that some very respectable and supposedly security-minded companies have failed to realise, that you need quality control at all levels -- and this means very knowledgeable people at all levels. Including the people who hit the last ENTER. :)
It doesn't help you have separate build, test, qualify and deployment systems, if at any time there is weak security.
danbi
Member
 
Posts: 227
Joined: 25 Apr 2010, 09:32
Location: Varna, Bulgaria


Return to General

Who is online

Users browsing this forum: vejnovic and 0 guests