I haven’t posted an update lately of new content on our site, so here’s a bit of a make-up post:

CERIAS Reports & Papers

• "Rights Protection for Categorical Data"
  17 January 2007, 11:00 pm
• "Privacy-Preserving Credit Checking"
  17 January 2007, 11:00 pm
• "Security in Wireless Sensor Networks - A Layer based Classification"
  22 January 2007, 11:00 pm

CERIAS Hotlist

• Plynt Penetration Testing Learning Center
  31 January 2007, 7:09 am
• FireMon by Secure Passage - Firewall and security device change control, auditing and optimization.
  29 January 2007, 9:10 am

CERIAS News

• Biometrics Lab: Brown Bag Lunches Highlight Recent Research
  25 January 2007, 9:32 am
• Call for Presentations: Midwest Security Workshop at Purdue
  8 February 2007, 10:22 am
• Registration Open: Columbus Incident Response Workshop (CCIR)
  15 February 2007, 2:40 pm
• Purdue Partners with LPD in Cyber Forensics
  19 February 2007, 1:09 pm

CERIAS Security Seminar Podcast

• Vipin Swarup, "Research Challenges in Assured Information Sharing"
  17 January 2007, 3:30 pm
• Wojciech Szpankowski, "WHAT IS INFORMATION?"
  24 January 2007, 3:30 pm
• Chris Clifton, "Mathematically Defining Privacy"
  31 January 2007, 3:30 pm

For the past few years, PHP security experts have been pounding on the heads of sysadmins to turn off register_globals.  While default installs of PHP turn it off, some popular web apps (especially older versions) insist on using it, so some webhost sysadmins will turn it on, presumably to make things go smoothly for their customers.  Oops!

CVE-2007-0233, what seems like the 300th Wordpress vulnerability in the last two weeks, reports an sql injection vulnerability in Wordpress 2.0.6 (which was only released 11 days ago).  The exploit appears to rely on register_globals being enabled, though:

funkatron@foo > php xpl.php foo.com /wp/

---------------------------------------------------------------------------
Wordpress < = 2.0.6 wp-trackback.php Zend_Hash_Del_Key_Or_Index /
/ sql injection admin hash disclosure exploit
(needs register_globals=on, 4 <= PHP < 4.4.3,< 5.1.4)
by rgod
dork: "is proudly powered by WordPress"
mail: retrog at alice dot it
site: http://retrogod.altervista.org
---------------------------------------------------------------------------

pwd hash   ->
admin user ->
exploit failed…

This is a good example of why web app security (and any security, for that matter) must be multilayered: on the hardware level, on the server daemon level, on the language environment level, and on the code level. So, for the love of god, STOP ENABLING REGISTER_GLOBALS, upgrade to Wordpress 2.0.7, and (shameless plug) use PhpSecInfo to audit your PHP environment.

Weblogs

• 2007: The year of the 9,999 vulnerabilities?
  Pascal Meunier - 11 January 2007, 3:31 pm
• Vulnerability disclosure grace period needs to be short, too short for patches
  Pascal Meunier - 5 January 2007, 12:31 pm

News

• CERIAS Director of Research Collaborates with I.B.M.
  9 January 2007, 12:19 pm
• CERIAS Affiliates Recognized for Outstanding Service 9 January 2007, 10:13 am
• E-voting Issues Persist, Spaf Claims
  9 January 2007, 9:58 am
• CERIAS Researcher Ninghui Li Receives ICICS Best Paper Award
  5 January 2007, 3:25 pm

Reports and Papers Archive

• “An Architectural Approach to Preventing Code Injection Attacks”
  7 January 2007, 11:00 pm

First off, a new build of PHPSecInfo is out: Version 0.1.2, build 20061218. Here’s what’s new:

• Code is now licensed under “New BSD” license. See LICENSE

• Added PhpSecInfo_Test_Core_Allow_Url_Include to test for allow_url_include in PHP5.2 and above

• fix bug in post_max_size check where upload_max_size value was being checked

• change curl file_support test to recommend upgrading to newest version of PHP rather than disabling support in cURL for ‘file://’ protocol

• removed =& calls that force pass by reference in PHP4, so as to not throw PHP5 STRICT notices. It means passing objects by value in PHP4, but this seems acceptable for our purposes (memory usage isn’t terribly high).

• Fixed bug in PhpSecInfo_Test_Session_Use_Trans_Sid where wrong ini key was requested (Thanks Mark Wallert)

• New, detailed README file with explanations and basic usage instructions - Now providing an md5 hash for releases

Here’s what I’m planning to do in the next few releases:

1. More detailed test results, including the current and recommended settings
2. A web-based “glossary” with more details on each test & how to fix problems
3. More tests!!! I especially need your help with this one!

I’m also going to look into options to reformat the test result structure, so it plays more nicely with templating systems. No promises on how this will go, but we’ll see.

 

I decided to not be all self-deprecating as I usually am with things like this, and admit that I’m really happy and proud to say that I was interviewed by Cal Evans for the Zend Developer Zone.

I guess the first question that comes to my mind is “Why did you build this?”
I built it because there was no good way to audit the security settings in your PHP.INI or your PHP environment. The average PHP user I feel is someone who can use an installer to install scripts on their server, get them running and do a little customization or hack up some code but they are not educated developers. These users have no easy way to check how secure their environment is. So I wrote PHPSecInfo to give these uses something easy to run and present the information in a format they are already familiar with.

Read the rest »

 

Also, I uploaded a new build of PHPSecInfo this morning.  This version fixes the errant Notices we were getting, makes it easier to extract test data for your own nefarious purposes, and fixes a bug with the curl file protocol test on PHP4.  The latter unfortunately just skips the test on PHP4 because I’m not sure how to do the check; suggestions are welcome.

Download: http://phpsec.org/projects/phpsecinfo/phpsecinfo.zip

Docs: http://phpsec.org/projects/phpsecinfo/docs/

What’s new:
v0.1.1
- Added PhpSecInfo::getOutput(), PhpSecInfo::loadAndRun() and PhpSecInfo::getResultsAsArray() methods
- Modified PhpSecInfo::runTests() to fix undefined offsent notices
- Modified PhpSecInfo_Test::setMessageForResult() to fix undefined offset notices
- Modified PhpSecInfo_Test_Curl_File_Support to skip if PHP version is

So we finally went public with PHPSecInfo as an official project of the PHP Security Consortium.

• http://phpsec.org/about/news/20oct2006.html
• http://phpsec.org/projects/phpsecinfo/
• http://phpdeveloper.org/news/6543

I just was interviewed by Cal Evans for the Zend Developer Zone, which was pretty cool—it was nice to talk to him again.  He said the story should be posted sometime this weekend or Monday.

We’ve made some significant changes to how people can view our Security Seminar Series:

• We’re now offering h.264/mp4 versions of the seminar videos, both as downloadable files and in a spanking-new video podcast.  Look us up in iTunes or the Democracy channel guide, and you’ll find us.  The 320x240 videos are not only higher-quality than what we’ve previously offered, but are also playable on portable players than support h.264 (we’ve tested it on 5G iPods)
     
• We will also look at encoding all of our previous recorded seminars to h.264/mp4 in the next few months.  Those that we have on DVD will be easy, but the ones more than a couple years old we only have on VHS, so they will likely take a lot longer.
• In the near future — at latest by summer 2007 — we will stop encoding our videos in RealMedia format.  The popularity of Real has faded a lot over the years, and most folks (including us) aren’t interested in installing it.  This would leave us without a streaming video format, but we’re not sure there’s a lot of demand for one now.  If there is, we will likely go with an embedded Flash video player rather than something like Windows Media.

If there is strong interest in providing other video formats, please let us know.  We may consider moving to 640x480 resolution for our videos now that iPods support the larger size, but we don’t want to push the file size to high and make for lengthy downloads.

If you have problems or feedback, please let us know in the comments section.

OSCON 2006 was a lot of fun for a lot of reasons, and was overall a very positive experience.  There were a few things that bugged me, though.

I met a lot of cool people at OSCON.  There are too many folks to list here without either getting really boring or forgetting someone, but I was happy to put a lot of faces to names and exchange ideas with some Very Smart People.  The PHP Security Hoedown BOF that I moderated was especially good in that respect, I thought.  There were also a lot of good sessions, especially Theo Schlossnagle’s Big Bad PostgreSQL: A Case Study, Chris Shiflett’s PHP Security Testing, and the PHP Lightning Talks (“PHP-Nuke is a honeypot” - thank you for the best quote of the convention, Zak Greant).

On the other hand, I was very surprised that the Security track at OSCON was almost nonexistent.  There were four sessions and one tutorial, and for a 5-day event with lots of sessions going on at the same time, that seems like a really poor showing.  The only other tracks that has security-related sessions were:

• Linux (including one shared with the Security track)
• PHP

which leaves us with the following tracks with no security-oriented sessions:

• Business
• Databases
• Desktop Apps
• Emerging Topics
• Java
• JavaScript/Ajax
• Perl
• Products and Services
• Programming
• Python
• Ruby
• Web Apps
• Windows

I can certainly think of a few pertinent security topics for each of these tracks.  I’m not affiliated with O’Reilly, and I have no idea whether the OSCON planners just didn’t get very many security-related proposals, or they felt that attendees wouldn’t be interested in them.  Either way, it’s worrisome.

Security is an essential part of any kind of development: as fundamental as interface design or performance.  Developers are stewards of the data of their users, and if we don’t take that responsibility seriously, all our sweet gradient backgrounds and performance optimizations are pointless.  So to see, for one reason or another, security relegated to steerage at OSCON was disappointing.  I hope O’Reilly works hard to correct this next year, and I’m going to encourage other CERIAS folk like Pascal Meunier and Keith Watson to send in proposals for 2007.

Chris Shiflett has posted a good piece in his blog on the potential danger of cross-domain AJAX scripting (digg here).  When Chris and I discussed this at OSCON, I was pretty surprised that anyone would think that violating the same-origin restrictions was in any way a good idea.  His post gives a good example of how dangerous this would be.

Just a reminder: next week I’ll be in Portland at OSCON 2006.  I’ll be moderating the PHP Security Hoedown wednesday night.  If you’re interested in meeting up and talking about web app security stuff or CERIAS, please drop us a line at oscon@cerias.purdue.edu.