From mock at obscurity.org  Fri Oct 13 17:41:44 2006
From: mock at obscurity.org (mock)
Date: Sat, 14 Oct 2006 00:41:44 +0000
Subject: [Van-pm] A couple of bits of local perl news
Message-ID: <20061014004144.GA3974@obscurity.org>

Well if you haven't already seen Stas Bekman's article on "Developing High
Performance Asyncronous IO Applications" (and incidentally using it to
punish spammers) over at ONLamp you might want to check it out.  I'm sure if
there's some interest he'd be happy to talk about it (hint, hint)

http://www.onlamp.com/pub/a/onlamp/2006/10/12/asynchronous_events.html

If you're using perl to do web applications you might want to check out this
advisory: http://seclists.org/fulldisclosure/2006/Oct/0177.html by yours
truly.

And finally anyone up for a get together over drinks/coffee/food?

mock

From mcli at brc.ubc.ca  Mon Oct 16 15:56:28 2006
From: mcli at brc.ubc.ca (Vincent  Li)
Date: Mon, 16 Oct 2006 15:56:28 -0700 (PDT)
Subject: [Van-pm] A couple of bits of local perl news
In-Reply-To: <20061014004144.GA3974@obscurity.org>
References: <20061014004144.GA3974@obscurity.org>
Message-ID: <56364.137.82.2.58.1161039388.squirrel@sparc.brc.ubc.ca>


> Well if you haven't already seen Stas Bekman's article on "Developing High
> Performance Asyncronous IO Applications" (and incidentally using it to
> punish spammers) over at ONLamp you might want to check it out.  I'm sure
> if
> there's some interest he'd be happy to talk about it (hint, hint)
>
> http://www.onlamp.com/pub/a/onlamp/2006/10/12/asynchronous_events.html

 UBC interchange server are under DoS attack lately. I believe they are
using Puremessage, but that is for content filtering, not for stopping
the bognet attack

Vincent

System Admin

BRC, UBC

From alex.pavlovic at taskforce-1.com  Mon Oct 16 22:28:57 2006
From: alex.pavlovic at taskforce-1.com (Alex Pavlovic)
Date: Mon, 16 Oct 2006 22:28:57 -0700
Subject: [Van-pm] A couple of bits of local perl news
In-Reply-To: <20061014004144.GA3974@obscurity.org>
References: <20061014004144.GA3974@obscurity.org>
Message-ID: <200610162228.58174.alex.pavlovic@taskforce-1.com>

Hi,

It is however worth noting, that such attack simply won't work if you are 
using Cat with plain DBI (traditional model) and placeholders. If you try
overflowing by sending more arguments then necessary, DBI will complain.

Simple example:

my $model = $c->model('MyApp::Model::DBI');
my $dbh = $model->dbh;

$dbh->do( 
	'UPDATE x SET y = ? WHERE z = ?', 
	{}, 
	$results->valid($x), 
	$results->valid($y) 
);

#or
$dbh->do( 
	'UPDATE x SET y = ? WHERE z = ?', 
	{}, 
	$c->req->param($x),
	$c->req->param($y) 
);

In this case we expect 2 arguments and no more, if either valid or param for 
$x or $y returns more then one, DBI will error out with something as 
following:

called with ... bind variables when ... are needed

The problem *really* relates to the code which builds SQL dynamically, 
especially as illustrated in your example on seclist. One solution to the 
problem as you point out is to force the result into scalar context.

The other solution is to abandon $c->req->param completely and switch over to  
$c->req->parameters if you are on Cat. Then you simply get either scalar or 
ARRAYREF back, instead of getting a list. ARRAYREF's cant be used without 
explicit deref, so it solves your problem.


Cheers.

-- 
Alex Pavlovic - CTO
TF-1 Inc. ( Custom development, consultancy and training )
http://taskforce-1.com

On Friday 13 October 2006 17:41, mock wrote:
> If you're using perl to do web applications you might want to check out
> this advisory: http://seclists.org/fulldisclosure/2006/Oct/0177.html by
> yours truly.
>
> And finally anyone up for a get together over drinks/coffee/food?
>
> mock
> _______________________________________________
> Vancouver-pm mailing list
> Vancouver-pm at pm.org
> http://mail.pm.org/mailman/listinfo/vancouver-pm

From mock at obscurity.org  Tue Oct 17 04:45:35 2006
From: mock at obscurity.org (mock)
Date: Tue, 17 Oct 2006 11:45:35 +0000
Subject: [Van-pm] A couple of bits of local perl news
In-Reply-To: <200610162228.58174.alex.pavlovic@taskforce-1.com>
References: <20061014004144.GA3974@obscurity.org>
	<200610162228.58174.alex.pavlovic@taskforce-1.com>
Message-ID: <20061017114535.GE3974@obscurity.org>

On Mon, Oct 16, 2006 at 10:28:57PM -0700, Alex Pavlovic wrote:
> Hi,
> 
> It is however worth noting, that such attack simply won't work if you are 
> using Cat with plain DBI (traditional model) and placeholders. If you try
> overflowing by sending more arguments then necessary, DBI will complain.
> 
> Simple example:
> 
> my $model = $c->model('MyApp::Model::DBI');
> my $dbh = $model->dbh;
> 
> $dbh->do( 
> 	'UPDATE x SET y = ? WHERE z = ?', 
> 	{}, 
> 	$results->valid($x), 
> 	$results->valid($y) 
> );
> 
> #or
> $dbh->do( 
> 	'UPDATE x SET y = ? WHERE z = ?', 
> 	{}, 
> 	$c->req->param($x),
> 	$c->req->param($y) 
> );
> 
> In this case we expect 2 arguments and no more, if either valid or param for 
> $x or $y returns more then one, DBI will error out with something as 
> following:
> 
> called with ... bind variables when ... are needed
> 
> The problem *really* relates to the code which builds SQL dynamically, 
> especially as illustrated in your example on seclist. One solution to the 
> problem as you point out is to force the result into scalar context.
> 
> The other solution is to abandon $c->req->param completely and switch over to  
> $c->req->parameters if you are on Cat. Then you simply get either scalar or 
> ARRAYREF back, instead of getting a list. ARRAYREF's cant be used without 
> explicit deref, so it solves your problem.
> 

You're right, using traditional DBI.pm you don't have to worry about this.
However, it's important to note two points.  First, SQL injection is not the
only place where this can bite you.  I've already found at least one software
package that puts a 'param' method into a config hash that also contains a
(supposedly) constant path.  Second, this was originally used to make the point
in my talk that what you don't know about the implementation of your ORM can
in fact hurt you.  More specifically, that your ORM can not always protect you
from SQL injection (I've got another example taken from DBIx::Class in my
slides as well).  So yeah, there are plenty of ways to not do the wrong thing.
The problem is that there are also plenty of ways to shoot yourself in the foot,
and programmers being what they are, well...

Ain't google code grand:

http://www.google.com/codesearch?as_q=%5C%24%5Cw%2B-%3Evalid%5C%28&btnG=Search+Code&as_lang=perl&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=

http://www.google.com/codesearch?as_q=%28%3D%3E%7C%2C%29%5Cs*param%5C%28&btnG=Search+Code&as_lang=perl&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=

mock

From mock at obscurity.org  Tue Oct 17 05:27:51 2006
From: mock at obscurity.org (mock)
Date: Tue, 17 Oct 2006 12:27:51 +0000
Subject: [Van-pm] A couple of bits of local perl news
In-Reply-To: <20061017114535.GE3974@obscurity.org>
References: <20061014004144.GA3974@obscurity.org>
	<200610162228.58174.alex.pavlovic@taskforce-1.com>
	<20061017114535.GE3974@obscurity.org>
Message-ID: <20061017122751.GH3974@obscurity.org>

On Tue, Oct 17, 2006 at 11:45:35AM +0000, mock wrote:
> Ain't google code grand:
> 

Hmmm this should be a bit tighter of a query:

http://www.google.com/codesearch?hl=en&lr=&q=%28%2C%7C%3D%3E%29%5Cs*%5C%24%5Cw%2B-%3Evalid%5C%28+lang%3Aperl&btnG=Search

http://www.google.com/codesearch?hl=en&lr=&q=%28%2C%7C%3D%3E%29%5Cs*%5C%24%5Cw%2B-%3Eparam%5C%28+lang%3Aperl&btnG=Search



From mcli at brc.ubc.ca  Tue Oct 17 10:07:15 2006
From: mcli at brc.ubc.ca (Vincent  Li)
Date: Tue, 17 Oct 2006 10:07:15 -0700 (PDT)
Subject: [Van-pm] A couple of bits of local perl news
In-Reply-To: <20061016225529.GB26317@mailchannels.com>
References: <20061014004144.GA3974@obscurity.org>
	<56364.137.82.2.58.1161039388.squirrel@sparc.brc.ubc.ca>
	<20061016225529.GB26317@mailchannels.com>
Message-ID: <60703.137.82.2.58.1161104835.squirrel@sparc.brc.ubc.ca>


>
> I like that typo -- bognet. Very appropriate and Freudian in nature.
>

:)

> How bad is it at UBC? Are there message delivery delays?? Lost messages?
>

There are some delays, the relay server doesn't implement recipient
validation, so a lot of email to invalid recipient were queued and wait
for Puremessage processing. I haven't heard message lost.

> Regards,
> Ken
>
> --
> MailChannels: Reliable Email Delivery (TM) | http://mailchannels.com
>
> --
> Suite 203, 910 Richards St.
> Vancouver, BC, V6B 3C1, Canada
> Direct: +1-604-729-1741
>
>

I run my own email server for my department, not impacted by this attack.
I think they are going to implement recipient validation through ldap.

Vincent

System Admin

BRC, UBC