Blog

  • Ajax Security Presentation up

    Here’s the quick and dirty preview of the new Ajax chapter of the Guide 2.1. It’s also some of the first real guidance anywhere on Ajax security – period. It was interesting to find so many apps adopting Ajax, but so little information on how to secure it.

    If anyone wants to proof the new chapter, please join the OWASP Guide development.

  • World of Warcraft: bigotry and interventions

    On bigotry

    As (more than) well documented elsewhere, Blizzard have some explaining to do. They selectively stamp out gay, bi, lesbian and transgender friendly activities and options (such as advertising GBLT friendly guilds or in game same gender marriage), but do not stamp out the hetero version of the same activity. Either ban both, or allow both. There is no half-pregnant.

    I think this story (found via Technorati) explains it best:
    In News Weekly

    Boing Boing is also running with it:
    Boing Boing

    WoW is littered with idiots using “gay” and “fag” as an offensive term, like “that’s so gay” or “you fag”. Yet these people are not warned or banned, as described in this post.

    Blizzard need to get their act together before someone uses their country’s anti-vilification laws to slap them upside the head and close down what seems to be a fairly popular game if some of my friends are any guide.

  • PHP Security Architecture: SABSA approach

    There are only a few acknowledged industry security architectures. SABSA (best documented in Enterprise Security Architecture by Sherwood, Clark and Lynas) is probably the best known.

    The various artifacts from this architecture include:

    Enterprise security layers

    SABSA Security Architecture

    Each of these layers needs to be thought about in a considered way:

    (Business) Drivers

    Why do you want X / How will it be used / Who will use it / Where should it be located / When will it be used?

    Answering these questions will help understand if something already exists (with PHP most likely), and understand the communities we need to talk to to understand their needs and desires.

    Then a risk assessment can be carried out to determine the relative risks of each area, and understand likely vulnerabilities based upon existing exploits.

    Occasionally, this process will pick up areas where there are missing areas of functionality in PHP. This then ends up on the roadmap for later versions.

    Conceptual Layer

    Training and awareness – DR / BCP – audit and review – authorization – administration – incidents – standards, etc

    Often these areas are well covered. The trick is to bring them under the one roof and ensure we’re all driving in the same direction. Some of the issues in a standard security architecture simply don’t apply to a language, which is cool as it means less work.

    Logical Layer

    Policy – classification – security services management – interop standards (WS Security et al) – audit trail, etc

    This is usually left to the programs written in PHP, but PHP needs to provide these services. The OWASP Guide provides a great deal of best practices, so the main activity here is to determine if the standard PHP frameworks contain adequate API in each area. For example, PHP is sadly lacking a secure audit class.

    Physical layer

    For PHP, this is mostly about configuration, but also the rawest possible implementation of the security trumvirate: confidentiality, integrity, availability. Again, PHP may need to grow to allow all of the areas here:

    certificate mangament

    Component layer

    A major win for security architectures in the last few years is the move away from crunchy on the outside, soft on the inside “edge” hardening towards trust boundaries. Identifying data flows from trusted components to other less trusted components is key to understanding the security risk.

    Therefore, this can be used to identify those API which normally perform this transition on behalf of programs, such as echo/printf/ IO in general, and so on. Each of these major trust boundaries needs to be investigated to ensure that there is a safe way to make the transition, whilst a raw / unsafe way remains for those few programs that need the raw / unsafe way.

    Conclusion for now…

    Well, that about wraps up this explanation. In the next installment, I’ll start enumerating the current risks and identifying business drivers. This is an important first step to creating a security architecture which will be robust.

  • PHP Security Architecture – Contextual Overview

    Overview

    The problem with PHP is that it has no security architecture. What do I mean by security architecture? A single pervasive vision for security, which will last for approximately five years with little or no design maintenance. A robust security architecture creates a balance between functionality and risk, and ensures that by default, simple activities and normal features create as little risk as possible.

    There is no point in a “safe” mode which prohibits most scripts of any consequence. For example, safe mode prevents most gallery applications from running. This wouldn’t be a bad thing if you’re a gallery hating hoster who wanted to prevent such apps from running, but this is not the case 99 times out of a 100. What is worse though, is that safe mode is trivially worked around if you want to completely 0wn the host using an attack script, but hard to work around if all you want to do is save some images to disk. The new security architecture must make balanced choices which allow apps to do their stuff, but not allow attack scripts to do their stuff.

    PHP has had several disjunct goes at implementing “security” features, but unfortunately, failed to implement them correctly. All these efforts requires modern safer programs to include code which tests if these options are enabled, and if so, to then undo their handiwork. Often such code is buggy and slow. For example, many hosters (incorrectly) have register globals enabled as many customer scripts “need” them. However, safer PHP scripts do not need register globals as they follow the usual OWASP model of validate! validate! validate! from the correct source ($_GET, $_POST, etc). So they have to undo the registered globals, requiring even more work and slowing each and every script down. If they get it wrong (and often they do; some programs actually look to see if register globals if off and put the old bad behavior back!) All this is wasted work.

    One of the key findings of the major sources of PHP vulnerability relate to many distinct configuration flavors. Hosters often run insecurely to maximize compatibility, and with “register globals”/”magic quotes” and “safe mode”, apps have at least 8 common combos which may or may not work for them. This makes testing significant PHP apps basically impossible. The new security architecture must provide a single correct configuration which programs can rely on, so there is no reason to enable these unsafe features. This also means that it is easy for auditors and reviewers to find code which relies on unsafe features, and even easier to find code which relies on the new security architecture so they can concentrate on the really dodgy stuff – bad design and silly processes.

    The pervasive security architecture explicitly reduces attack surface area of any PHP 6.0 script to manageable levels, and controls all security features in a cohesive and orthagonal way. A key goal is to ensure that existing scripts will not need to be modified (but also do not benefit … unless it is easy and safe to do so), but new applications which are aware of PHP 6.0 will automatically get the safest programming experience.

    Of course, it is possible to write insecure programs in any language if you try hard enough. What I want is the easiest way is also the safest way.

    Security Architecture Objectives

    The major objectives for the PHP Security Architecture are:

    • By default, the new architecture uses a low attack surface area approach, disabling any features which have a security outcome
    • The easiest way to do something, is also the safest way
    • If we can provide security without coding, then that will happen (think freebie XSS protection)
    • Backward compatibility is not broken, but hosters and admins are free to enable this mode (yes, by default unless you ask for the new architecture, the old scripts will not run)
    • Unsafe constructs and patterns, like mysql_query() which cannot be made safe at any price, do not run in the new architecture. At all.
    • Safe constructs, like PDO are unchanged and require no porting
    • The basic architecture pattern is “deny unless permitted” as it applies to operating system and network resources
    • Never introduce another broken security idea into the new security architecture. ie, no more “register globals” or “magic quotes”. Either the new feature is the lowest risk way of achieving an outcome, or it is not introduced. This will require significant peer review.

    Compliant scripts invoke the new security architecture, but once invoked the entire script must be compatible with the new architecture. The new security architecture has to be wholistic and apply to all functions. But as this is a lot of work, the initial effort has to be to secure the securable, and remove access to the unsecurable.
    Bad security patterns in need of solving

    There is no point in fixing broken API, so I will not delve into straight security “fixes” for existing PHP applications. However, I have reviewed the top five PHP related issues and worked out their root causes.
    The five things are:

    • File inclusion attacks, usually resulting in remote command injection
    • Remote command injection
    • Validation failures, particularly XSS attacks
    • File system attacks
    • and lastly, configuration related attacks which makes the attack so much worse

    Creating secure patterns and fixing APIs which remove these issues permanently will advise the security architecture’s overall look and feel, and it will help us create “safer” PHP-like constructs. There is no point in producing Java-like or .NET like constructs on top of PHP – PHP developers use PHP for a reason: it’s a pretty simple language to pick up and fast to make things happen.That is not to say that there will be no J2EE or .NET influences, particularly if one of those does something very well, and PHP currently does not have an equivalent API. For example, if we need a new API for feature X already present in another platform, then there is little reason to create an API with tiny detail differences. All that means is that programmers moving from other platforms to PHP need to learn the PHP nuances, but the more likely instance is that they will get it wrong and there will be subtle bugs. A typical example is that in .NET, structured exception handling is pervasive, whereas in PHP, we use PHP’s loose typing to return bools, occasionally -1, occasionally throw an exception and sometimes a string. We should be careful about return results like this, particularly if we pick up an API wholesale from somewhere else.

    Sandbox

    The sandbox as it stands in the runkit is insufficient. What we need is isolation so that each application has a level of isolation from the underlying environment, and other applications. Hosters often run hundreds of users on each host and many applications may exist in each account, such as a CMS, blog and gallery … just as I do here. All are in PHP. The apps can see and change each other’s resources like config and temporary files, which is not an ideal situation.
    Obviously, some apps require less isolation than others, and some require tight integration (a CMS and an integrated forum software for example), so a model must exist which allows such integration without opening up an entire full trust model as today.

    Bringing old features into the fold

    There is no point in creating a massive new API just for security architecture, but there needs to be a way to identify those areas which are affected. Luckily, a great deal of the API is already in PHP, so it’s “just” a matter of securing the boundary in the core between PHP applications and the underlying operating system.

    However there are gaps in PHP requiring new API and ideas to allow basic security activities

    • The idea of an intrinsic authorization model which code can rely upon to be there
    • Privilege levels / trust model, running as the lowest possibile privilege and allowing impersonation and elevation of privilege without secret storage
    • Secret storage and other crypto API, particularly as it relates to database connections
    • Implementing encrypted connections to databases and LDAP stores by default unless unencrypted is required

    Conclusion… for now

    There is much work to do. I will blog my thoughts here regularly and refine the overall approach. I will obviously find some hidden corners of PHP of which I am currently completely unaware, so I will take advice from anyone who has experience in these areas.

  • Upgrade to WordPress 2.0 complete

    We are now running in WP 2, and due to increasing levels of comment spam, I’ve removed the ability for guests to post comments.

    Cute kitten
    Cute kitten

    Those of you who blogged at Many Tubbies already have accounts and do not need to create a new account if you feel like leaving a comment. E-mail me if you’ve forgotten your password.

  • 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/

  • Best blog entry ever

    From Groklaw:

    I want Boies Schiller to know that Groklaw is open to any of their lawyers who wish to write articles for us, and if that isn’t possible now, contact me after you lose

    Love it.