Want to have your server pwned? Easy: Run PHP More than 78 per cent of all PHP installations are running with at least one known security vulnerability, a researcher has found. Google developer advocate Anthony Ferrara reached this unpleasant conclusion by correlating statistics from web survey site W3Techs with lists of known vulnerabilities in various versions of PHP. …
You don't know that there are new bugs/undiscovered old bugs at the time of the upgrade.
I'm not convinced that what you don't see won't hurt you is a practical philosophy when it comes to software. History shows that there is likely to be bugs in a new version. One way or the other, you take your chances. I think that a big part of the problem regarding unknowns is that updates often don't just fix know problems, but include additions and features - thus adding to the chances of failure.
>updates often don't just fix know problems, but include additions and features
Maybe I am missing something but I thought that is the whole reason you pay RH big bucks (to push systemd but I digress) is so you get the security bug fixes without new features if you so choose. Yes bug fixes often come with their own risks and even sometimes open yet new security holes (especially it seems like in Windows land) but that is why companies pay for many of the IT pros reading this to test those fixes first before deployment.
"I'm not convinced that what you don't see won't hurt you is a practical philosophy"
That's not what I said or proposed. If you have a known vulnerability, a patch or upgrade being the only solution, then you have to take the risk that you are not adding new problems unless you have the time and ability to fully scrutinise the source code of the patches or upgrade.
Is the risk that an upgrade or patch might introduce a new and as yet unknown vulnerability higher than fixing a known vulnerability? I'd say no.
> If you have a known vulnerability, a patch or upgrade being the only solution
Actually, it's not "the only solution". As I understand it, a sane security approach will assume that your systems are vulnerable, and seek to identify, minimise, and control the consequences of a break-in.
This, of course, does not mean that one should leave the door wide open, but security patches are but one element in the equation, not the ("only") solution itself.
It's a fucking awful language.
Still lots of people like it and write good (well reasonable), secure (well not too fucked) code in it.
@asdf
That's a bit of a leading question – I guess only Javascript is another webbie language – every other language tends to come from another domain.
I'm not arguing as to what you can and cannot do with the language but very specifically about the rather obvious lack of design of the language itself. Like Javascript, PHP was thrown together to scratch a particular. They have both succeeded in spite of this shortcoming.
This post has been deleted by its author
I was thinking of particularly of Ruby on Rails and while the language is not web only it might as well be. Still honestly my age is showing some but not a lot in the webbie domain strikes me as particularly elegant. It often seems like an ever more high level technology/framework/language flavor of the week, exclusively RAD focused, charlie foxtrot used by millennial hipsters designers (not developers) who don't even understand the levels upon levels of software they are using above the bare metal.
I was thinking of particularly of Ruby on Rails
That's one particular framework, which is reasonable for a particular domain and shit for everything else. The ActiveRecord pattern is one of the many examples of poor designs from lazy or stupid programmers, though that isn't helped by SQL syntax: a "wire" interface for set algebra would be a much better way for client code to talk to servers.
But, while I don't like the Ruby syntax, there's no denying that quite a lot of thought has gone into the language.
In one sense it's very difficult to do the web nicely thanks to the stateless http protocol and fuck-ups like HTML forms (look and smell like MIME elements but you can't nest them). But having a universal protocol and no runtime lock-in also has its advantages.
designers (not developers) who don't even understand the levels upon levels of software they are using above the bare metal.
I hear what you're saying, but please don't over generalise.
Some of us have already written our own memory management libs, string manipulation, array handling, and UI frameworks several times. It's time to use someone else's, now.
When I last used PHP (v4), it was great for whipping up something quick and simple and was one of the best solutions at the time (a bit like JS).
You mean just like virtually every other language and technology in webbie land?
PHP is particularly awful. It manages to beat Perl for inconsistency and redundant features - an impressive achievement - and it has a collection of design infelicities and inherently-insecure functions (including, notably, some of the "security" ones) that makes the C standard library jealous.
Yes, Ruby on Rails combines poor scaling with the security nightmare that is Active Record. Yes, Node.js suffers from being, well, Javascript, with its type-unsafe Self-like object model1. Yes, ASP.NET is Windows-only and relatively heavy. And so on. You can find something to object to in any language.
But PHP is an especially execrable pile of crap upon crap. It's a big ball of ill-conceived ad hoc bits tossed together. And - as with so many languages - few of its practitioners seem to want to use the less-stupid ones (even OO PHP seems to be relatively uncommon).
And as the article points out, there's a wide range of PHP versions in use, so if you want to write code for use on multiple sites, you have to target the common subset. I ran into version (and configuration) issues several times when I put together a simple PHP data access layer the students in my web-design class last year. They typically didn't have control over the PHP version and configuration - they couldn't afford relatively expensive VM hosting packages, so their sites were on shared systems and they got whatever the hosting provider wanted to install.
1Of course ECMAScript 5.1 fixed some of the problems with earlier versions. And of course almost no one uses those features.
Still lots of people like it and write good (well reasonable), secure (well not too fucked) code in it.
And lots of people write fucking awful code in it.
I was once called in to fix a CMS that had lost ~70% of its content. It turned out that a (fairly aggressive) web spider had got into the admin section and spidered all the "delete" links.
The entry route was that an inexperienced editor had accidentally posted a link to his edit page, rather than the published version. But the security breach was that PHP had several methods to retrieve environment variables (e.g. current username), with a big red warning on the doc page to tell you that mixing those methods would lead to credential leakage. The CMS in question did exactly that, so the web spider had erroneously been given admin credentials just before it came across that duff link...
Vic.
I doubt any serious admin is accurately showing the actual version they are running, it's long been standard practice to report completely different Apache, PHP, OpenSSL etc variants in the server banner.
I'm surprised this guy is basing his research findings on the results on that site ... option 1: he doesnt reallise those results are highly likely to be miles out, so he's a dufus, or option 2: he does reallise, but published his research built on dodgy foundations anyway, in which case he's a dufus.
"I doubt any serious admin is accurately showing the actual version they are running"
It doesn't matter, this security through obscurity technique you're describing is so pointless. Have you thought about this technique to display any other version besides the latest version? If you have, which of what?
You don't bother with version numbers or any kind of string something like phpinfo() prints, you just fire your best exploits. I've never see a reason why anyone would bother playing (duck/duck/goose) with strings, unless you want to waste time and pass up targets. Hell, doing this guarantees an extra log.
PHP is a good scripting language though. I read back sometime in 2007 that one of the developers broke off and started listing security flaw after security flaw, but not out of angst, out of interest of seeing the language remaining a competitor. I know some PHP, but I'm not proficient (apparently I'm not alone :-/). I always found it super quick to pick up, but much less flexible with complexed tasks without making a huge plate of spaghetti, so I'd have to fall back to C for somethings (as usual). Still though, from the messes I've made in PHP without having clear alternatives of remedy in the language, I can see how many many holes go left unchained.
"It doesn't matter, this security through obscurity technique you're describing is so pointless. Have you thought about this technique to display any other version besides the latest version? If you have, which of what?"
Dude, obviously I would be running the most up-to-date and secure version I can possibly find, I just don't see the value in advertising it correctly. I agree it adds little security, however my point was that basing research on figures that were based on data highly likely to be very wrong was probably not quite so bright.
"It doesn't matter, this security through obscurity technique you're describing is so pointless. Have you thought about this technique to display any other version besides the latest version? If you have, which of what?"
The pointless thing is people who talk about security through obscurity being pointless. They're the ones who don't understand what that term means nor the fact that real security is done through layers upon layers of measures of varying degree of sophistication - all designed to obscure.
I always wonder whether such people are employed by the NSA/GCHQ to dumb down developer's guard online on doing everything they possibly can to achieve security.
Fire the best exploit you can? That's no more than spray and prey and that means the layer of obscurity achieved it's goal of frustrating you, delaying you (for however little time you may think it is) and over-time as the system is updated, keep you guessing. Unless you're so bad-ass of course to find a 0-day, which the majority of "hackers" aren't.
PHP is as secure as any other "web" development languages. The ability to secure it lies with the people who makes and maintains the entire stack. The problem with PHP and other mainstream web development languages is it's too easy to learn, too easy to find off-the-shelf packages and plugins, too easy to make websites without understand what every single line of code does and without understand how the web truly works, too easy to be lazy. Thus you end up with a huge amount of amateur developers with limited abilities or computer science background working on PHP websites for companies who relies on these "professionals" to do a job.
That said, this Google engineer's so called "research" is flawed even though it is generally true. No one in their right mind would rely on a single page blog post with no real datasets or details on how the data is obtained to make a real informed conclusion. Too many statistics are "obtained" and manipulated just to justify the writer's generalised conclusion.
In fact, having read this person's blog, I wonder why it is even news worthy.
> That's no more than spray and pray
Most servers are pwned to make spambots, malware distributors, and DDos machines, so spray and pray works just fine.
If your main concern is hackers targeting your everso important site because it's really everso important, those are not (usually) the threats you're looking for.
That's no more than spray and prey[sic]
Spray and pray is how the vast bulk[1] of exploits are used; they're bulk-fired from botnets. I'm currently getting a metric fuckton of it from Argentina - and, having taken no significant part in the Falklands Conflict, I'm pretty sure that's not personal. It's just that botnet attacks are so cheap, that's what you get.
PHP is as secure as any other "web" development languages
The stats would tend to disagree with you there. PHP is an easy language in which to get stuff running quickly - but there are a number of jaw-dropping flaws in pretty much every release, and portability isn't that great, so you tend to have crap old versions still running...
Vic.
[1] There are obviously targetted exploits from assorted bad guys - but these are a minority of attacks.
>>"It doesn't matter, this security through obscurity technique you're describing is so pointless."
You've missed the point. No-one is saying that. The point is that this person's research on how many servers are vulnerable (and to what) is based on published version numbers. When disabling or altering the published version information is standard practice.
I loosely know Anthony aka ircmaxell in an IRC context, if he wasn't hiding I'd be saying this:
Backports, backports, no seriously, backports...
The methodology is sketchy at best in the context of most people will be running distro-installed versions with security fixes backported into what are at face value older "insecure" versions - and there's no reliable way to measure this, which is why one doesn't ordinarily bother. Don't get me wrong there's probably a lot of insecure PHP installs but the version doesn't have to be misreported for the secure/not secure data and drawn conclusions to be *wildly* incorrect.
it's long been standard practice to report completely different Apache, PHP, OpenSSL etc variants in the server banner
.... Seriously? Home hacker scene, ahoi!
Next up: hanging hare's paw on the server room door.
"Next up: hanging hare's paw on the server room door."
Not only did you beat me to it, but your answer is completely bulletproof! Gongrats! (You really can tell when someone has dealt with security!)
P.S. Mine was was to post a Tweet that said "NO" every time my server was asked if it's hackable...but blood is much better! (Plus I didn't want to have a Twitter daemon :-/ ) Happy New Year!
I doubt any serious admin is accurately showing the actual version they are running,
Oh, holy fuck! If you start messing around with version numbers for that kind of shit you really will have problems.
Distros may choose to backport security fixes to older versions (though there are plenty of cases where that isn't really possible) in which case they may manage their own patches but otherwise the version number is the only way to know if you're secure or not. The hackers don't bother checking version numbers, they just use brute force vulnerability/feature detection as anyone who's ever read an error log will know.
I doubt any serious admin is accurately showing the actual version they are running,
Not to pile (too much) on the hate you seem to be getting - but a serious question...
Did you also remember to turn off PHP's 'Easter eggs'? If not, then with a single URL I can tell which version of PHP you're running without needing to resort to the idiots method of last resort (spray and pray) or rely on the version headers.
As others have said though, if all else fails, brute force will find its way through to whatever version you're using.
>>"Oh, holy fuck! If you start messing around with version numbers for that kind of shit you really will have problems."
Before leaping in with conclusions, make sure you understand what is being talked about. It's a config setting in Apache that decides whether or not it will accurately report version numbers to a requesting client. It's not messing with actual version numbers or what will be reported internally. It's override for external requestors. What the OP is talking about is very common practice.
I doubt any serious admin is accurately showing the actual version they are running
You might find it eye-opening to survey some of the great many cheap hosting sites that offer PHP, then. Most of the ones I've seen operate on the "install a default configuration and forget it" principle.
Of course, that may not qualify as a "serious admin" by your definition; but in that case serious admins are a rare breed.
Did the writers consider that perhaps many PHP installations are blocked from upgrading because the upgrade is likely to break whatever's running at the time, resulting in unacceptable downtime? Meaning the IT guy's caught between Scylla and Charybdis: either enforce the update and explain the likely-extended downtime and lost revenues to Accounting or keep the system running and risk pwnage and potential lawsuits?
You've just described what an IT Manager's job role is. If your IT Manager is NOT doing this then they don't deserve the job.
IT Managers don't do this. Their job is primarily to say "no" to the BOFH's security suggestions. And then to tell upper management that it is the BOFH's fault that they pwnage happened.
Their secondary function is to fall down lift shafts. But far too few fulfil this function.
Vic.
Surely the first/routine port of call is to apply the security patches. Version upgrades are primarily to add new features.
This article's failure to understand how security issues are routinely addressed in the OSS world leads me to doubt its usefulness about anything. Is it really about selling W3 Tech's products?
PHP is popular because it is good.
What are the real alternative 'secure' solutions, that wont break eveything when upgrading, that are maintained regularly and that are human readable?
IIS, Java, Perl, ActiveX, Flash ?
( Flash and ActiveX are just there for giggles please dont take seriously, even though some of you might)
If you can't offer a viable alternative that's not as riddled with holes, then you're part of the problem behind the problem. IOW, the problem is that PHP is riddled with holes. The problem behind the problem? It's still the best option on offer...short of going static, which is usually not an option. The way it's being put, you got four drinks: arsenic, strychnine, ricin, and cyanide. Pick your poison...
It's not the best option on offer, having worked with a lot of web programming platforms I can promise you it is as close to the worst as you can get without being old ASP with VBScript, but it is passably quick, easy to get started with and offers cheap ubiquitous hosting.
A little like JavaScript in the browser, PHP is an awful language that you can run on servers everywhere. It's actually a bit more awful than JavaScript, which at least has a programming language at its core, but the price is right so it gets used very widely.
One of the major downsides, which this article alludes to, is the way that PHP updates tend to break the existing behaviour of the platform, so migrating an application to a new version is a non-trivial activity as you need to go through a very in-depth QA cycle to be confident that there are no changes that will wreak havoc in your codebase.
PHP is popular because it is good.
Nah, I don't think that it's because it's good, but because (IMO) it's relatively easy to write code in, has good documentation, the feature set is well-suited to the task of web programming and its syntax is easy for people to get to grips with (somewhat like Basic or Pascal). It also seems to be be the sort of language that appeals to managers in that the code is fairly easy to understand and maintain so you can treat programmers as a fungible resource.
The security problems tend to be more with the server than the code itself (at least historically), but as with any web programming language, developers still need to be aware of the basics of writing secure code in the first place. So no insecure "eval" statements or calls to external programs, always assume that user-supplied data is hostile and always use prepare/execute instead of naked SQL queries. I'm sure that there are other common security pitfalls, but I'd guess that the majority of them stem from those three points.
As for me, I much prefer Perl. I dislike the verbosity of PHP, but the main reason that I think that Perl is better is down to the -w and -T options. Perl is much better at helping you understand the unintended consequences or potential bugs in your code. Taint checking in particular makes it very hard for you to write insecure code, since it won't even let you run the thing if it detects that you're not sanitising your inputs correctly.
I've never used IIS or ActiveX, so I can't comment. I don't think that Java or Flash are even real competitors due to (a) needing browser plugins and (b) those plugins having a terrible history of insecurity.
@Frumious
"Nah, I don't think that it's because it's good, but because (IMO) it's relatively easy to write code in, has good documentation, the feature set is well-suited to the task of web programming and its syntax is easy for people to get to grips with (somewhat like Basic or Pascal). "
Doesn't your argument give weight to the fact that what you just described is actually what most people want from a language? For me, that would be the definition of good.
Of course it is also possible to use to use synatically more difficult languages, or more precise yet difficult to read but what is there to truly gain from that... The web for example requires very dynamic languages that are quick to program.
I coded in assembler for a year or so and as much as I enjoyed what I did, I would not class it as a good language to program in ( although it is excellent for certain tasks, I was hooking and chaining interupts at the time)
Doesn't your argument give weight to the fact that what you just described is actually what most people want from a language? For me, that would be the definition of good.
LOL. Yes, kind of. I guess it is a good language overall, but it's not a patch on Perl, IMO. I just find PHP to be too verbose and boring to actually like it. I think that the original context was about being good for security, among other things, and as I said, Perl's -w and -T checks put it head and shoulders above the competition.
Mind you, maybe I'm a bit perverse in my (programming) tastes. I love constructs like Duff's Device and the Schwartzian Transform and have been known to use them when appropriate.
I do not see that Perl's "-t|-w" flags and similar kludges makes it good. If it was really good, they would not be needed as the basic system would catch the risks. I keep encountering clever Perl wrappers that come up with the sort of warnings that "-w" would have flagged. But because Perl can be somewhat awkward, the author just ignored the risks and released the code.
I've done some interesting and useful jobs with Perl, from small to many thousands of lines. But my recent small-scale use of Python is changing me into the equivalent of the smoker who has given up smoking. This was promoted by more having to read other people's Perl to try to work out what was going on.
My experience with PHP is limited and out of date. But as I recall, the attractive bit is that it is easy to write pretty, screen-orientated stuff. A bad bit, as with Perl, is that object orientation is forced into it clumsily and relying almost entirely on the consistency, understanding and self discipline of the programmer.
However, I do agree that a language should, like Pascal, be reasonably straightforward to read and write, secure and well documented. Both Pascal and C appeal to me as they are small enough (or at least the first couple of Cs were) for one to have the whole syntax in one's head, small, efficient. C++ and Java fail because one needs to know not just the syntax (which in C++ is big enough) but the scores of different class libraries to get even basic things done, each with a big rivalling the bible, but much more obscure.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
