From lecar_red at yahoo.com Thu Dec 1 15:30:10 2005
From: lecar_red at yahoo.com (Lee Carmichael)
Date: Thu, 1 Dec 2005 15:30:10 -0800 (PST)
Subject: [Mpls-pm] Using Mason's $m from within a perl module
In-Reply-To: <694fa1450511301050h511f710fv1c81a4c41fa0a66a@mail.gmail.com>
Message-ID: <20051201233011.42567.qmail@web31402.mail.mud.yahoo.com>
Hello Dave,
> package Foo;
>
>
> > our $m = HTML::Mason::Request::instance;
> >
> sub login_required
> > {
> > unless ($m->session->{'userid'}) {
> > $m->comp('login.mhtml');
> > $m->abort;
> > }
> > }
> >
>
> but this always fails saying that $m isn't
> instantiated. Everything works
> fine if I define the $m locally within each sub, but
> that gets annoying. I
> thought our should scope to the entire package.
> What's the propper way to
> take this on?
I think the 'our' is making the variable exist but
Perl sets this up at module load time. At that point,
there isn't request so the 'instance' method return
'undef' (per
http://masonhq.com/docs/manual/Request.html#accessor_methods
).
When you stick it inside the 'login_required' sub, it
grabs an instance at runtime, after it has been
created so everything is ok.
You probably want to add a 'init' method to this
package to do something like:
package Foo;
our $m;
sub init { $m = HTML::Mason::Request->instance(); }
sub login_required { ... }
I haven't tested this but I think it will do what you
want.
Please note, that this will cause a copy of that
request instance inside the package var '$m' until the
next request. You probably don't really want to do it
leave this around. You could add a 'cleanup' sub like:
sub cleanup { $m = undef; }
These additional subs can be called in the user of
this module like:
Foo::init();
Foo::login_required if ($some_condition);
Foo::cleanup();
I'm not sure what the code that calling this looks
like so I cannot really make any other recommendations
besides you might want to make Foo an object which can
automate the cleanup for you. Just in case, you end up
somewhere where 'cleanup' cannot be called from. Also,
you might want to look into 'MasonX::WebApp' since it
provides a slick framework for doing stuff like this.
Good Luck,
Lee
__________________________________________
Yahoo! DSL ? Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
From lecar_red at yahoo.com Fri Dec 2 08:57:31 2005
From: lecar_red at yahoo.com (Lee Carmichael)
Date: Fri, 2 Dec 2005 08:57:31 -0800 (PST)
Subject: [Mpls-pm] Apress offer for user groups
Message-ID: <20051202165731.27726.qmail@web31414.mail.mud.yahoo.com>
Hello Everyone,
It seems that Apress offers books, coupons, and other
stuff to user groups.
http://www.apress.com/userGroups/index.html
Maybe it would be good to sign up the mongers.
Take Care,
Lee
__________________________________________
Yahoo! DSL ? Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
From twists at gmail.com Fri Dec 2 09:29:02 2005
From: twists at gmail.com (Joshua ben Jore)
Date: Fri, 2 Dec 2005 11:29:02 -0600
Subject: [Mpls-pm] Fwd: Perl format string integer wrap vulnerability
In-Reply-To:
References: <20051201085741.GD28337@5002.rapturesecurity.org>
Message-ID:
I'm changing my topic. Instead of doing anything on using delayed
evaluation expressions, I think its worth talking about writing
modules that analyze compiled perl. I wrote one
(http://perlmonks.org/?node_id=513486) in half an hour yesterday to
find modules with exploitable sprintf bug. Its at . To use it, you
just load it.
I used it to produce a report of exploitable code in core perl and the
stuff I had in my site-lib. http://perlmonks.org/?node_id=513527
BTW, does anyone know how to get perl to do something more useful than
segfault when given a bad format? The bug is triggered by using a
format like "%" . ( $n + MAXINT ) . "d". The number is getting
assigned into a signed integer and this is where the problem is, I
guess. Somehow this allows an attacker to write to arbitrary memory.
How?
Josh
---------- Forwarded message ----------
Date: Thu, 1 Dec 2005 00:57:41 -0800
From: robert at dyadsecurity.com
To: bugtraq at securityfocus.com
Subject: Perl format string integer wrap vulnerability
SUMMARY. perl suffers from an integer wrap overflow inside the explicit
parameter format string functionality, this has been confirmed to be a
vector for remote code execution.
Date Found: September 23, 2005.
Public Release: TBD.
Application: perl
Credit: Jack Louis of Dyad Security
BACKGROUND. perl is a cross-platform scripting language. for more
details see Perl.org
DESCRIPTION. Value over INT_MAX(value of I) inside explicit parameter
format string (%I$n) causes integer wrap in the efix (32bit signed
integer) variable inside the function Perl_sv_vcatpvfn (see example 1)
(sv.c:~9360). Allowing for a write value anywhere in memory exploitation
vector (see example 2). Further, heap corruption itself is possible (see
example 3), as are more exotic non-reliable $PC redirection (see example
4). From what we have seen the first exploitation method is the only
valid one. ImmunitySec has found a generic method of controlling the
first condition with a good amount of robustness and success. Perl
itself is not directly vulnerable to remote attacks due to this flaw,
however any perl program with format string vulnerabilities is. The
vulnerability is not to limited DoS (as reported previously) but remote
code execution as well as information leakage and DoS.
IMPACT. Perl itself is not generally impacted by this vulnerability,
but programs with format string vulnerabilities (Dyad Security has
confirmed that several programs available at this time have this
specific issue) can be vulnerable to remote code execution. Information
about creating a robust generic exploit is forthcoming, so public
knowledge of exploitation methods for this issue is in the cards.
AFFECTED VERSIONS. Perl 5.9.2 and perl 5.8.6 have been tested and found
to be vulnerable on linux, freebsd, dragonflybsd on the ia32 platform.
It is assumed that a much larger range of software and platforms are
also affected, as the sv.c seems to remain seemingly static over time,
however this is not confirmed.
EXAMPLE 1.
$ gdb myperl/bin/perl5.8.7
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) break sv.c:9232
Breakpoint 1 at 0x80c0df0: file sv.c, line 9232.
(gdb) set args -e 'printf("%2147483647\$n");'
(gdb) run
Breakpoint 1, Perl_sv_vcatpvfn (sv=0x812d180, pat=0x0, patlen=0,
args=0x0, svargs=0x8133080,
svmax=0, maybe_tainted=0xbffb72cb "") at sv.c:9232
9232 in sv.c
(gdb) p efix
$1 = 2147483647
(gdb) set args -e 'printf("%2147483648\$n");'
(gdb) run
Breakpoint 1, Perl_sv_vcatpvfn (sv=0x812d180,
pat=0x80000000 , patlen=0,
args=0x0, svargs=0x8133080,
svmax=0, maybe_tainted=0xbfb0640b "") at sv.c:9232
9232 in sv.c
(gdb) p efix
$2 = -2147483648
(gdb) cont
Modification of a read-only value attempted at -e line 1.
Program exited with code 0377.
(gdb) set args -e 'printf("%2147483649\$n");'
(gdb) run
Breakpoint 1, Perl_sv_vcatpvfn (sv=0x812d180,
pat=0x80000001 , patlen=0,
args=0x0, svargs=0x8133080,
svmax=0, maybe_tainted=0xbfe69b9b "") at sv.c:9232
9232 in sv.c
(gdb) p efix
$3 = -2147483647
(gdb) cont
Program received signal SIGSEGV, Segmentation fault.
Perl_sv_setiv (sv=0x0, i=0) at sv.c:1652
1652 in sv.c
(gdb) bt
#0 Perl_sv_setiv (sv=0x0, i=0) at sv.c:1652
#1 0x080b6349 in Perl_sv_setuv_mg (sv=0x0, u=0) at sv.c:1743
#2 0x080c0e06 in Perl_sv_vcatpvfn (sv=0x812d180,
pat=0x80000001 , patlen=0,
args=0x0, svargs=0x8133080,
svmax=0, maybe_tainted=0xbfe69b9b "") at sv.c:9232
#3 0x080e923b in Perl_do_sprintf (sv=0x812d180, len=1,
sarg=0x813307c) at doop.c:713
#4 0x080de48a in Perl_pp_prtf () at pp_sys.c:1489
#5 0x080ad038 in Perl_runops_standard () at run.c:37
#6 0x080615c7 in S_run_body (oldscope=1) at perl.c:2000
#7 0x080613ff in perl_run (my_perl=0x812d008) at perl.c:1919
#8 0x0805e61f in main (argc=3, argv=0xbfe69da4, env=0xbfe69db4) at
perlmain.c:98
(gdb) x/i $eip
0x80b61a8 : mov 0x8(%ebx),%edx
(gdb) i r ebx edx
ebx 0x0 0
edx 0x812d180 135451008
(gdb)
EXAMPLE 2.
#0 Perl_sv_setiv (sv=0x815f821, i=0) at sv.c:2184
2184 SvIVX(sv) = i;
(gdb) x/i $eip
0x80c815c : mov %esi,0xc(%eax)
EXAMPLE 3.
#0 0xb7e69fb0 in malloc_consolidate () from /lib/tls/libc.so.6
EXAMPLE 4.
#0 0x09010e50 in ?? ()
FIXES. Due to the information that has already been leaked we moved up
the release date of this advisory. There is no official fix for this
issue as of yet. We have provided a sample patch for the 5.9.2 version.
See http://www.dyadsecurity.com/perl-0002.html for additional
information and a link to the patch.
SPECIAL THANKS.
Special thanks to Dave Aitel and Bas Alberts of ImmunitySec for the
donation of resources and leading the difficult phase of exploit
verification research. If you wish to obtain any exploits or further
detailed information regarding this vulnerability, please contact
ImmunitySec.
LEGAL NOTICES.
Copyright (C) 2005 Dyad Security, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of Dyad Security, Inc. If you wish to reprint the whole
or any part of this alert in any other medium other than electronically,
please email advisoryreprint at dyadsecurity.com for permission.
DISCLAIMER.
The information in the advisory is believed to be accurate at the time
of publishing based on currently available information. Use of the
information constitutes acceptance for use in an AS IS condition. There
are no warranties with regard to this information. Neither the author
nor the publisher accepts any liability for any direct, indirect, or
consequential loss or damage arising from use of, or reliance on, this
information.
SEE ALSO.
http://www.dyadsecurity.com/webmin-0001.html
=== End of Forwarded Message
From andy at petdance.com Fri Dec 2 09:33:47 2005
From: andy at petdance.com (Andy Lester)
Date: Fri, 2 Dec 2005 11:33:47 -0600
Subject: [Mpls-pm] Fwd: Perl format string integer wrap vulnerability
In-Reply-To:
References: <20051201085741.GD28337@5002.rapturesecurity.org>
Message-ID: <20051202173347.GF5709@petdance.com>
On Fri, Dec 02, 2005 at 11:29:02AM -0600, Joshua ben Jore (twists at gmail.com) wrote:
> BTW, does anyone know how to get perl to do something more useful than
> segfault when given a bad format? The bug is triggered by using a
> format like "%" . ( $n + MAXINT ) . "d". The number is getting
perl5-porters is currrently working on creating patches for public
release. Watch perlfoundation.org and other news sources for
information when I make an announcement
Andy
PR guy for TPF
--
Andy Lester => andy at petdance.com => www.petdance.com => AIM:petdance
From ken at mathforum.org Fri Dec 2 17:14:28 2005
From: ken at mathforum.org (Ken Williams)
Date: Fri, 2 Dec 2005 19:14:28 -0600
Subject: [Mpls-pm] Fwd: Perl format string integer wrap vulnerability
In-Reply-To:
References: <20051201085741.GD28337@5002.rapturesecurity.org>
Message-ID:
On Dec 2, 2005, at 11:29 AM, Joshua ben Jore wrote:
> BTW, does anyone know how to get perl to do something more useful than
> segfault when given a bad format? The bug is triggered by using a
> format like "%" . ( $n + MAXINT ) . "d". The number is getting
> assigned into a signed integer and this is where the problem is, I
> guess. Somehow this allows an attacker to write to arbitrary memory.
Well, it's only arbitrary memory within that process's address space,
not arbitrary memory in the computer. So on *nix a person can't
elevate their privileges unless they can find a script running as
someone else and it does printf("%$variable"...) and they can change
$variable by supplying some tricky input. Sort of a tall order, but
since it's not impossible it's a security bug.
On platforms where a process can write to memory outside its address
space, it's sort of a moot point, as on those systems the attacker
could just write a simpler program to do so.
From dd at davedash.com Tue Dec 6 19:00:07 2005
From: dd at davedash.com (Dave Dash)
Date: Tue, 6 Dec 2005 21:00:07 -0600
Subject: [Mpls-pm] Dereferencing complicated things...
Message-ID: <694fa1450512061900m1e571e8dr2f0e39a05d60ea1b@mail.gmail.com>
Let's say I have a hash:
$a = {b=>(1,2,3)}
and
$b = \$a;
Is there a way given $b->{b} to dereference that into the array that is
(1,2,3) ?
Currently I end up doing a lot of annoying steps, but it'd be nice if
something like @($b->{b}) would work...
--
Dave Dash
612.670.0621
3555 Fremont Ave S, Mpls, MN 55408
http://citybikemap.com/
http://davedash.com/
AIM: davesdash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/mpls-pm/attachments/20051207/6417e371/attachment.html
From eric at urbanrage.com Tue Dec 6 19:36:47 2005
From: eric at urbanrage.com (Eric Estabrooks)
Date: Tue, 06 Dec 2005 21:36:47 -0600
Subject: [Mpls-pm] Dereferencing complicated things...
In-Reply-To: <694fa1450512061900m1e571e8dr2f0e39a05d60ea1b@mail.gmail.com>
References: <694fa1450512061900m1e571e8dr2f0e39a05d60ea1b@mail.gmail.com>
Message-ID: <439658CF.8070200@urbanrage.com>
Dave Dash wrote:
> Let's say I have a hash:
>
> $a = {b=>(1,2,3)}
>
> and
>
> $b = \$a;
>
> Is there a way given $b->{b} to dereference that into the array that
> is (1,2,3) ?
>
> Currently I end up doing a lot of annoying steps, but it'd be nice if
> something like @($b->{b}) would work...
>
well you could do:
$a = {'b'=>[1,2,3]};
$b = \$a;
@c = @{$$b->{'b'}};
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3174 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.pm.org/pipermail/mpls-pm/attachments/20051207/86d5e1ad/smime.bin
From dd at davedash.com Tue Dec 6 19:41:42 2005
From: dd at davedash.com (Dave Dash)
Date: Tue, 6 Dec 2005 21:41:42 -0600
Subject: [Mpls-pm] Dereferencing complicated things...
In-Reply-To: <694fa1450512061900m1e571e8dr2f0e39a05d60ea1b@mail.gmail.com>
References: <694fa1450512061900m1e571e8dr2f0e39a05d60ea1b@mail.gmail.com>
Message-ID: <694fa1450512061941r7cd2112cla381e41d2ef5d311@mail.gmail.com>
Actually correction that should be
%a = {b => [1,2,3]}
On 12/6/05, Dave Dash

wrote:
>
> Let's say I have a hash:
>
> $a = {b=>(1,2,3)}
>
> and
>
> $b = \$a;
>
> Is there a way given $b->{b} to dereference that into the array that is
> (1,2,3) ?
>
> Currently I end up doing a lot of annoying steps, but it'd be nice if
> something like @($b->{b}) would work...
>
> --
> Dave Dash
> 612.670.0621
> 3555 Fremont Ave S, Mpls, MN 55408
> http://citybikemap.com/
> http://davedash.com/
> AIM: davesdash
--
Dave Dash
612.670.0621
3555 Fremont Ave S, Mpls, MN 55408
http://citybikemap.com/
http://davedash.com/
AIM: davesdash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/mpls-pm/attachments/20051207/b0f04c84/attachment.html
From ken at mathforum.org Tue Dec 6 21:09:35 2005
From: ken at mathforum.org (Ken Williams)
Date: Tue, 6 Dec 2005 23:09:35 -0600
Subject: [Mpls-pm] Dereferencing complicated things...
In-Reply-To: <694fa1450512061941r7cd2112cla381e41d2ef5d311@mail.gmail.com>
References: <694fa1450512061900m1e571e8dr2f0e39a05d60ea1b@mail.gmail.com>
<694fa1450512061941r7cd2112cla381e41d2ef5d311@mail.gmail.com>
Message-ID:
Double correction, it should have been:
$a = {b => [1,2,3]}
The solution you're looking for is:
@result = @{ $b->{b} };
The rule is that following the '@' character must either be the name of
an array (such as "result" above, or a simple scalar such as $x (e.g.
@$x) that holds an array reference, or brackets that evaluate to a name
or an array reference.
If you're running under "strict" mode, no evaluation is allowed in the
latter "name" case, it must be a literal name (e.g. @{ result }).
The following code demonstrates a few ways of accessing the same array:
@x = (1..10);
print @x; # Literal
$y = \@x;
print @$y; # Hard reference
print @{\@x}; # Hard reference
print @{"x"}; # Soft reference
print @{lc("X")}; # Soft reference
Of course, if you want to address individual elements of your $b->{b}
structure, you can just use $b->{b}[0], $b->{b}[1], etc.
-Ken
On Dec 6, 2005, at 9:41 PM, Dave Dash wrote:
> Actually correction that should be
>
> %a = {b => [1,2,3]}
>
> On 12/6/05, Dave Dash