cat slave diary

Category: Rants

  • PHP Insecurity: Failure of Leadership

    About a week or so ago, I wrote to webappsec in response to Yasuo Ohgaki (書かない日記) post about some issues with PHP’s security model.

    For some time, I’ve been worried about the direction of PHP. As many of you know, I helped write XMB Forum and now help write UltimaBB. XMB in particular is an old code base, and UltimaBB, a descendant from XMB. I’ve done a lot to protect that code base from attack, and luckily, we’ve been missed despite some doozy and silly security issues. After writing PHP forum software for three years now, I’ve come to the conclusion that it is basically impossible for normal programmers to write secure PHP code. It takes far too much effort.

    PHP needs a proper security architecture, and support for newbie programmers. PHP’s raison d’etre is that it is simple to pick up and make it do something useful. There needs to be a major push by the PHP Development team to take this advantage, and make it safe for the likely level of programmers – newbies. Newbies have zero chance of writing secure software unless their language is safe.

    Think about Logo for a minute. Logo can do some interesting things, but it is not a commercially useful language because it cannot do much. But it is an excellent teaching language. PHP is like Logo – it’s a simple and easy way to get into serious web development. It is possible to write large applications in PHP, so it is useful at that level. But it is inherently unsafe as it can do far, far more than Logo.

    There are so many ways to break PHP that it is impossible for even experienced security professionals like me to code in it securely all the time. There are nearly 4000 function calls, and many of them have unintended consequences or have been inappropriately extended by something else.

    At every turn, the PHP Development Team have made truly terrible “security” choices:

    • register_globals
    • magic_quotes_gpc (and friends)
    • PHP wrappers (see below)
    • safe mode
    • output, XML, LDAP, and SQL interfaces that intermingle data and query elements, which by their very nature are impossible to protect against injection attacks

    All of these are broken. They are disjunct and have no security model. Some of the features, like PHP wrappers, are not well documented, and are a clear and present danger to PHP scripts and worse, they do not obey the weak “safe” mode restrictions. I bet few PHP coders are aware of them, let alone their security impacts.

    http://php.net/manual/en/wrappers.php

    PHP coders cannot rely upon their script running in a Unix or Windows environment, so they must code to the least common denominator. Hosters rarely upgrade to the latest PHP, even though it is safer. Even though programs could be ported to safer interfaces like PDO or the OO mysqli parameterized queries, programs cannot support this mode as it’s too rare. Even PEAR modules are hard or impossible to import in a shared environment, so favorites like PECL or ADODB which might help are not available, so programs ship with outdated and vulnerable libraries.

    So why this whinge?

    PHP must now mature and take on a proper security architecture, an over arching security model which prevents or limits attack surface area until the application explicitly asks for it. There can be no other way. If you look at Bugtraq, every day, 10-50 PHP applications are broken mercilessly. This cannot continue. Hosters cannot pay the price for the PHP development team’s lack of security expertise.

    I wrote back to webappsec that we as security experts should offer our counsel to the PHP Development Team. The only response I received from Yasuo-さん. His response included an exploit of the PHP wrappers (as above) which is completely unaffected by any safe mode implementation. He also suggested I contact Rasmus Lerdorf, one of PHP’s creators who leads the PHP development team.

    I e-mailed Rasmus, and although it’s the new year, I have yet to receive a reply. I get a lot of e-mail, but I make an effort to reply to all of it. I wish others would do the same – it is only polite. [ Edit: 24/1/2006 – I have a reply from Rasmus. Apparently, he saw Chris’s blog and thus this rant, and replied. ]

    It is time to stop complaining. The time for forgiving PHP’s weaknesses are over – it must stop, and stop now. PHP 6.0 is still in development, and it should be so clearly more secure than anything before it, that hosters will upgrade to it, in the same way they have not upgraded to PHP 5.0.

    It is time to いたします。

  • Cars that park over two spots…

    I don’t know what it is about Sluggardly Utility Vehicles and parking like you own the road, but within five minutes of each other, I spotted a white Territory covered in an advertising hoarding take up two spots next to the disabled spots at McDonald’s crowded carpark, and a Nissan Patrol taking two spots at the local shopping center. I took photos of both with my mobile. Maybe I’ll start a site for this: crapdrivers.com or something.

    Everyone has to park the car legally to get their license. I don’t know how or why these cranially challenged drivers thought they had the right to park in two spots, but it’s disgusting. I wrote to the company who had the hoarding on the car to complain. If I get a reply, I’ll post it here.

  • No succour for murderers

    This morning, Singapore, a supposedly civilized first world nation, murdered an Australian citizen, Nguyen Tuong Van. He had smuggled drugs, and for that he deserved a long sentence commensurate to his crime.

    But not murder at the hands of a state.

    From this day forth, I will not be supporting any barbaric regime which murders people. I will be changing my Optus mobile (owned by Singtel) to some other carrier. I will be avoiding US owned carriers for the same reason unless it is demonstrable that they are not state owned.

    If you are part of a Government who kills and you need or want my advice or me to work for you, until you morally grow up, you are denied access to advanced research and technology.

    If such regimes wish to be a part of the civilized world, they will act like it and abolish the death penalty.

  • Kansas – the laughing stock of the world

    From CNN:

    At the risk of re-igniting the same heated nationwide debate it sparked six years ago, the Kansas Board of Education approved new public school science standards Tuesday that cast doubt on the theory of evolution.

    Story here

    If the idiots on the Kansas Board of Education jump off a bridge, they would be affected by the “theory” of gravity, whether they believed in this “unproven” theory or not. The six “yes” votes on the board are first prize idiots who will directly harm their students forever – it’s hard to get a job in marine biology or in bio-industries if you don’t know about the basics of science in your field. I hope Kansas parents sue the pants off of the Board for rampant stupidity and harming their progeny’s chances of success in later life.

    For the real scoop, go here:
    http://www.talkorigins.org/

  • PHP Insecurity: File handling and remote code execution

    For better or worse, there are a lot of novice programmers hammering away at PHP scripts all over the planet. It is one of the most common web scripting languages. However, it’s simply too hard for a newbie PHP programmer to write secure PHP code. As I’ll demonstrate, it’s also impossible for even security minded PHP professionals to keep their applications secure due to the way PHP manages change to its ever-growing API. Their culture of “add stuff, but stuff the security implications” has to stop. Don’t get me wrong, I love change. I just don’t love the way the PHP project goes about it.

    Let’s take a non-hypothetical instance. Some functions are very familiar to Unix folks, like fopen(), fread(), fclose() and so on. In Unix, the semantics of these functions and the security issues surrounding them are well understood. However, in PHP, fopen() and friends are heavily overloaded, and gain new functionality between even minor PHP releases. For example, by default, PHP’s fopen() and several friends can open any file on the Internet. Producing a canonical filename which is safe is basically impossible in PHP.

    Take a typical PHP application using templated languages. A typical implementation will enumerate a directory to see what files are available (English.lang.php, русски.lang.php, etc) and then try to “fix” it up. The attacker will then try to substitute ../../../../../etc/passwd or something similar. Nothing new here for our Unix friends. But what about going offsite? Well, the top vulnerability for PHP applications in 2005 is remote file inclusion and it uses this exact same mechanism.

    The usual type of thing I see all the time:

    $language = $_POST[‘language’] + “.lang.php”;
    include ($language);
    …

    Of course, the security people reading this are going “nononononno!”. But to the average PHP programmer, why should it be any harder? PHP just made a basic idea very hard to get right. This is not to say J2EE or ASP.NET are invulnerable to this type of boneheaded programming, but they don’t allow you to include files from over the Internet and then evaluate their contents.

    What about if we move to file_get_contents() instead of including the result? file_get_contents is rarely used as it is a PHP 4.3.0 and later construct, and PHP coders are reluctant to use new fangled calls when old ones will do. However, it is no better! It STILL allows us to read the file directly from a URL or via a wrapper, like php://output (which acts like echo… with the usual association of data… XSS city), or php://filter/resource=http://www.example.com … and this is NOT restricted by allow_url_fopen. Who comes up with these settings?

    Programmers are usually surprised at the wide number of places what used to be local file operations are able to be used for remote file and file filters. The job is made harder because PHP keeps on changing its mind about what is available. What used to be a safe application with PHP 4.2.x is no longer safe in PHP 4.3.x or PHP 5 – just because PHP changed.

    Accompanied by extremely fragmented documentation (ie “see Appendix L” or read the usually extensive comments to see how the functions ACTUALLY work), it takes experience to program PHP’s file operations. With a very low barrier of entry, PHP needs to keep these advanced features to those who know what they’re doing. However, it’s far too late. PHP is used by programmers of many different skill levels. The average Joe programmer has no help in hell of writing a safe PHP application.

    In the meantime, let me plug Chris Shiflett’s brand spanking new PHP Security book from O’Reilly:
    Amazon Listing

    If you want to write secure apps in PHP, you need that book.

  • On the failure of genre

    On the weekend, I bought two CDs:

    • Goldfrapp – Supernature
    • Ministry of Sound – Sessions

    I couldn’t find the Goldfrapp. At all. Despite being heavily promoted in store, with a large 10×10 m poster dominating the front window, they did not have any on a display stand, and they didn’t put it in the music genre sections I would have expected it, like “Popular” or “Electronic” or “World”.

    The morons had put it into the “alternative” section. The CD is about as alternative as Pink Floyd’s The Wall, which is (correctly) in the popular section.

    Genre-ification of music does not serve customers. I’m sure it makes the CRM enabled music execs wet their pants, but it leaves me cold and I buy a *bucketload* of music every year.

  • On DDoS protections

    A number of gambling websites recently suffered massive distributed denial of service (DDoS) attacks. These are not the first, and certainly not the last massively DDoS attacks. In fact, the problem will only get worse as consumers place ever more unsecured equipment on the Internet via fast (enough) broadband links.

    The attacks

    The attacks are assumed to be of Eastern European origin, due to the mail servers they choose to use and their broken English. However, even this cannot be guaranteed. What is clear is that they do not write the attack tools, they just use them as part of their extortion racket.

    These attacks can be characterized into three major categories:

    • spoofed UDP traffic
    • spoofed SYN traffic
    • HTTP data sinks

    The first two are utterly preventable and should have never been able to traverse the Internet. The originating ISPs (wherever they are) are ultimately responsible for their customer’s traffic. My view is simple: if an ISP allows spoofed packets as part of a DDoS network, the proportion of losses should be recoverable from these criminally negligent ISPs.

    Countermeasures: network equipment manufacturers

    About the only welcome aspect of a shakeout in network equipment manufacturers is that it is simpler to address one of the core sources of the DDoS problem: ISPs letting spoofed traffic through their networks. If all digital modem concentrators, DSLAM’s and HFC headends had default and unstoppable anti-spoofing, high rate spoofed DDoS attacks would be impossible.

    How to categorize ISPs into those who do the right thing (block customer traffic with non-routeable source addresses)?

    My view is that a scheme which has a dynamic list of BGP AS’s of ISPs who have been audited as “source IP address correct” should be established. After a certain cut off date, any ISP who refuses to be audited, or does not return a audit status, will suffer the consequences of the Internet not passing their traffic.

    This would in a short stroke eliminate spoofed IP traffic as a source of DDoS packets. Even the largest bot nets contain only a few thousand hosts, and with real source IP addresses, technical schemes to rate limit IP addresses, dynamically deny IP addresses and other anti-DoS techniques could be implemented.

    The next portion of the DDoS answer is how to deal with infected hosts. My personal view is that a responsibility is shared between the owner of the infected equipment, the ISP and the vendor of the application or operating system which allowed the infection to take place.

    For example,

    • the customer should have a personal firewall on by default and run modern anti-virus software with recent updates;
    • the ISP should be aware of customers who have unusual traffic patterns and can easily recognize Trojan ports or activities;
    • vendors of software such as (but not limited to) mIRC, Kazaa, or Windows, contribute to the total number of DDoS bots in existence by not putting in controls which prevent distribution or control malware activity;
    • by default, any operating system which provides methods which enable direct access to the network card, or allow the creation of arbitrary packets should have an indefeatible error message for which the end user would have to agree prior to the application being able to communicate with the outside world.

    Although it can be successfully argued that this would only raise the bar in terms of how clever the malicious bots would need to become under such a regime, the reality is that few possess the skills to create new malware. There are a limited number and heavily inter-related attack bots in existance today. By raising the bar, the bots would be:

    • identifiable by source IP address
    • have limited spread
    • have limited opportunity to run successfully

  • Security architecture and document reviews

    I work in an environment where there is “implicit” review. That is, if you don’t respond in time during the comments period, you are assumed to sign off on the document. This is very dangerous for someone like me – I have tenuous links to the client organization, and although my hosting contracting organization has professional indemnity insurance to cover me, it only covers me as long as I’m not negligent. For example, not reviewing a document and letting it through.

    Now this is where it gets tricky – I feel I have to review the documents with my name in them. However, if I review a document, I’m not about to let a sub-standard document through. I will review it and offer advice not just as the subject matter expert, but also on ways to improve the document and make it better. Often times, these are accepted and all are happy.

    However, today I reviewed a truly sub-standard solution architecture document (known as a SAD). SADs normally take the business requirements and maps out in fairly specific non-techo language how a system will work and how it interacts with other systems. The developers take the SAD and turn it into an implementation of the SAD after writing a detailed design (DD). The DD will basically agree with the SAD’s approach, but minor details and extreme technical details will be included.

    For example, a well written SAD will have something like this for every feature which is required to be implemented:

    User Login Sequence

    Scenarios

    • User wants to log into the application.
    • Attacker may want to brute force the application

      • Sequence

    • User is registered using process defined in 3.2.1.
    • User navigates to web site and is presented with a login form (defined in 5.4.3)
    • User fills in username and password
    • System will take username and password and check to see if the password is correct. The username and password are stored in the user registry, following the security principles outlined in section 1.2.3 (ie no reversible passwords).
    • If the credential is correct, move to the foo page (see section 4.3.2)
    • If the password has expired, move to the password reset page (see section 1.4.2)
    • If the password is wrong, display a generic error message (as per message defined by the business – see Appendix A)
    • …

    You get the picture.

    Unfortunately, the SAD I reviewed today was so wooly that I think it described a system which had between three and five new screens. I’m not sure, you see. So I gave that feedback, along with another 60 mistakes I found. This didn’t go down too well with the author. I had forgotten the prime directive of security consultants – couch your criticism nicely rather than being brutally honest.

    How to write a report

    However, looking back at it, there is another issue – the author is not qualified to write SADs. No one is – there’s no definitive form that anyone can agree on.

    I feel that to ensure high quality software and secure solutions, there needs to be the One True Way to improve on the production of solution architectures. Five years ago, I think I’d be pushing the line that there needs to be a security architecture as well as a SAD, but no, we need solid solution architecture. Security is a key attribute – this is not in doubt, but everyone is responsible for security, not just the security slaves.

    That’s why I am writing a Solution Architecture Book rather than a Security Architecture Book.

  • Low life scuzz buckets in disabled spots

    Nothing makes my blood boil more than selfish pricks.

    I was at the supermarket today. As per usual, a born to rule fuckhead had parked their oafishly large SUV in the disabled spot whilst not displaying a disabled sticker. I realise that sometimes you might be carting around elderly relatives, so I let it go when I went in.

    When I came back, the Toyota Pratto truck was still there, and an able bodied woman was behind the truck putting shopping in. I gave her the evil eye. There were non-disabled spots more than capable of taking her stupidly large monster not even 10 metres away. Would it have been so hard to park legally? Would her legs have given out if she had to go those extra few metres with her shopping trolley?

    So TFN 247, you are outed as a low-life scuzzbucket. I hope that one day, you are disabled and can’t get a disabled parking spot … ever. That way you’ll know exactly how selfish you have been.

  • car dealers

    I had my new Citroen serviced on Friday. Why do certain types of service industry jobs attract people who hate and loathe their customers? I know that the IT has the Bastard Operator From Hell and the LART (luser attitude re-adjustment tool, aka a baseball bat), but generally we take pride in doing a good job even if we hate our customers.

    Not so in the automotive world. I got the car back with greasy hand prints on the side of the seat and a greasy foot print in the door. The service rep tried blaming me for them. Unbelievable. I don’t have oily feet (my garage is new) or hands when I last needed to adjust the seat (which is when I bought it, and I think I would have noticed (and cleaned) the marks if I had seen them). I stared him down in utter disbelief.

    Then he told me how I could clean it, suggesting Sard wonder soap or some piece of crap that will not actually work on car materials. I have a large range of car detailing products, I will get it off, but I will not be returning to this vulgar crowd again.