[ukigumo]

It may come as a surprise to many, but on high security services such as banks, servers that handle critical data cannot have any build tools installed or usable.

Having said this, I've found limited proof that a particular language is any safer than another as it comes down to safe coding policies and risk mitigation strategies.

[feld]

That's BS obscurity. If they can get a shell they can download a compiler anyway.

[ukigumo]

I'm not sure what you mean, so my answer below might be a misfire in which case I apologize.

If an attacker can get a shell they would still need to have access to a exec environment and / or breakout of a "jail" or other protected space. Protecting your data store can prove tricky but there are quite a few products and techniques that basically reduce the amount of data that can be breached by any one attack vector (database firewalling, query filtering, etc).

Tidying up an OS + middleware (and having a decent L7 firewall) is sufficient to deter most attacks which is all you can hope for unless you can afford a good security architect and a response team and even that does not guarantee 100% security.

Obscurity, by itself, is not a solution but is often one of the most effective tools to deter simple attacks.

[feld]

Once they have a shell they're free to do what they want. Local root exploits, etc are all fair game -- and there are plenty of 0-days out there. In fact, removing the compiler doesn't help; a lot of attackers and bots run a script to detect the system environment and auto-download what they need to move on. Remember: jails can still be broken out of, and there is some really neat work in the research space of attacking hypervisors...

There are numerous things you could remove from an OS install to make their lives a bit harder (dtrace, systemtap anyone? you can sniff passwords easily...), but once they have a shell and a directory with write access it's game over. You're better off leaving the tools there but having your auditing throw a serious fit when a compiler, etc is executed unexpectedly on a production box.

So yes, I think it's bunk to claim that removing a compiler will provide meaningful security benefit. In fact, I believe this has been suggested a few times to FreeBSD by users (don't install compilers, etc by default!) and was dismissed as ineffective for the same reasons.

Work harder to prevent the bad guys from getting that far. Keep your systems well patched. Have a thorough auditing and monitoring system in place. Use containerization and segregation everywhere possible. Limit scope of access. Some points you made apply here as well. Maybe once you've mastered all of those arts you can play with the obscurity angle.

edit: and L7 firewalls... I'm on the fence there. There has been some movement in that area by security researchers equating them to antivirus... they're only as good as their definitions, and a targeted attack will bypass it. They also seem to give a false sense of security and let people be lazy. Security in layers is important, though.

edit2: don't get me wrong, you should be hardening your production boxes (and dev... so the environments match...) but removing a compiler is not high on my list

[ukigumo]

I don't completely agree with you here.

My experience has been 80% + in Solaris and OVM for SPARC (also some AIX with LPARs) and I am not aware of any exploit that breaks the non-global zone security boundary to the control domains or other NGZs. I'm fairly sure I haven't seen any in FreeBSD either but I could be wrong here.

In Linux, I am aware of privilege escalation exploits involving symlinks and complied objects (out of the top of my head, might be old or inaccurate) but overall the thinking goes that having a compiler available opens up a few extra attack vectors while not having it installed doesn't break anything at all.

I published an entry level article on building a gold image with ubuntu where I try to map some best practices and my experiences here: https://blog.ukigumo.eu/anatomy-of-a-gold-image/ I never got around to publish the rest of the series but still plan to, so feedback is welcomed. Maybe I should point out that I'm not exactly a sysadmin though :-)

Regarding L7 firewalls, I have recommend that they are installed and _used_ in all environments I've worked in (banks, insurance companies, payment services providers, stock exchanges, etc) and I do agree with you that often the feeling is that if they are installed and set to defaults it's good enough which is worrying but that's not to say that they should be abandoned.

Security is all about risk mitigation and all we can do is not to make it too easy for our platforms to be broken into and data to be lost, and I think if you dismiss obscurity you might need to try out something like setting up a couple of honeypots with commonly used services in your network (one with default ports one without for instance) and keep some notes of your experience :-)

[spacemanmatt]

Would you say that there is 'limited proof' that C is inherently more dangerous than Java?

I would estimate PHP is inherently more dangerous than C.

[ukigumo]

I would say it is easier to shoot yourself in the foot with C than with Java or other managed runtimes.

PHP code can be as secure as anything else, in my experience, but the end state solution has to take into account the possible risks and mitigate them accordingly.

Putting it in another way, would you say it's more dangerous to have a DB and java appserver running on the same "server" or having a PHP application in one box in one network segment and a DB server in another box, different network segment and with different privileged credentials?

[sanswork]

Why would you say that? What does C offer as a language that makes it more secure in your mind than php?

[brohee]

It's not so much the language itself the issue, as both C and PHP weren't made with safety in mind, it's the kind of programmers that the language encourage.

IMHO, C cell defined semantics makes it simpler to master. PHP is an easy language to get stuff done, but a pretty hard one to master, I would say possibly harder than C. E.g. very few people actually make no mistakes about the behavior of the == operator... (http://habnab.it/php-table.html)

C is safer in the sense that it filters out the incompetent better than most languages, people which don't have a decent understanding of it are unlikely to produce something that doesn't crash fast if it even compiles.

PHP permits anyone to be somewhat productive, that's good in some cases, but in most cases you want someone who understand what he's doing...

[sanswork]

So nothing about the language itself?

C certainly doesn't filter out incompetent developers at all. The fact that it is less popular means it is naturally filtered out these days with most people who work with it being older but there are plenty of incompetent C developers building internal software all over the world even today. I mean if you checked any internal codebase written in C today you're likely to still find multiple places where the developer has shot themselves in the foot over memory management. It wasn't that long ago that people were speaking the same way about C programmers because of all the exploits/simple bugs years after STSFFAP was released.

>PHP permits anyone to be somewhat productive, that's good in some cases, but in most cases you want someone who understand what he's doing...

In most cases you don't have a choice so it doesn't matter which language you give them.

[brohee]

> I mean if you checked any internal codebase written in C today you're likely to still find multiple places where the developer has shot themselves in the foot over memory management.

This is absolutely nothing compared to the incredible stuff you can see auditing the average PHP code base... Most PHP programmers don't understand all the implicit conversions taking place, and that's a source of many bugs. I can't really blame them as many of them make no sense whatsoever. PHP is a really hard language to master, and most people that put the effort actually start to see PHP for what it is and go to a less insane language...

[sanswork]

I've seen it. I use to develop php full time between 6-9 or 10 years ago. I developed C full time 12-14 years ago. I'm not trying to say php is a great language here and I avoid it completely these days. I'm saying php the language has nothing to do with this type of security issue and the language itself isn't going to be more insecure than any alternative. The same developer building wordpress in C is still going to allow for uploading any file in an executable way since they want to enable people to upload plugins from the interface.

[tveita]

There are no systems to my knowledge where the server will compile and execute a .c file from a directory when accessed.

Yet that seems to be the default configuration for many PHP installations unless you specifically guard against it it. A common PHP vulnerability is just the user uploading a php file and then accessing it.

[ukigumo]

This is what I mean with knowing what risks your application / framework / language will bring and mitigating them accordingly.

(edited for clarity)

[sanswork]

So you're saying the issue isn't with the php it is with all interpreted languages? Then compile your php before upload.

>A common PHP vulnerability is just the user uploading a php file and then accessing it.

A common PHP vulnerability is allowing uploads to a folder where code is allowed to be executed. That isn't a fault with the language but with lazy developers and admins.

[dscrd]

>Having said this, I've found limited proof that a particular language is any safer than another as it comes down to safe coding policies and risk mitigation strategies.

Proof is right there in the article. To have PHP on the live server is a security risk, period.

[sanswork]

Having a general purpose blog system on the same server(and sharing the same database credentials and having the ability to write files) is a security risk it has nothing to do with the availability of php.

[ukigumo]

My point exactly. If instead of wordpress they had a copy of some other big-old-java-thingie it would have been just as exploitable.

[ukigumo]

I disagree. Having poor security "hygiene" is dangerous, the tools that you select to shoot yourself in the foot are less important than having a hardened server with minimal services and installed software (and host intrusion detection, etc..)