Rice University logo
Top blue bar image Comp327: Introduction to Computer Security
Blog and homepage for Rice's Comp327

Archive for April, 2011

Vuze Security Audit (Group 1)

Saturday, April 23rd, 2011

WordPress Security Audit – Group 3

Tuesday, April 19th, 2011

Course schedule is updated

Wednesday, April 6th, 2011

With reading for tomorrow on honeynets and next Tueday on Stuxnet.

Group 2 – CVE-2006-0105

Wednesday, April 6th, 2011

Perspectives on Race Conditions

Wednesday, April 6th, 2011

Today looking into one CVE I bumped into this nice description about perspectives on single core vice multi core race conditions and using existing frameworks to accomplish the task. Sebastian Krahmer who has come up with a POC code for CVE-2011-0727 where he describes using cpu cores to simplify the race condition. Mr. Krahmer proves his description of his previous race condition using pppd and how there is some tuning involved with different cpu speeds. This race wins by beating the scheduler on a single core system. Now looking at the POC code for multi core systems I am left wondering what other exploits that can be simplified that are not currently known where the multi core systems makes this a trivial task.

Group 1 CVE-2009-4484

Monday, April 4th, 2011

XSS on a Page Rank 5 Site

Sunday, April 3rd, 2011

So I was visiting a website that I frequent pretty often to download recordings (non-copyright, legal fyi) and check the latest posts on the forum (link not included for security). Then recently, I searched for a recording and noticed that the search entry was displayed on the page:

Well, are you thinking what I’m thinking?

I decided to enter a :
<script> alert(“H@CKED”) </script>
and sure enough

This page rank 5 website was indeed vulnerable to cross site scripting.
To test what inputs could be put in I decided to see if standard html would display correctly, perhaps a paypal buy now button?

And to get rid of the ” in Track’s Title…”, one could just put in a <!– to comment it out:

What’s even worse is that the search entry is made via a GET in the URL.

Now this is a big problem. An attacker just needs to craft a URL and get some one to click on to potentially:

  • Convince them that they can donate to the website, when they are really donating to the attacker
  • Steal account login via javascript, which is a particular problem given that the forum has over 8000 users

The best way to deal with this problem would be to sanitize inputs or display them as text, escaping from the html

In order to deal with this ethically, the administrator of the website will be contacted and informed. A public
announcement will be made 30 days after informing the administrator if no change is made.

Group 5 CVE-2009-0696

Sunday, April 3rd, 2011