Re: random token re-used in subsequent requests [SOLVED]

[Vincent Veyron]

On Tue, 31 May 2016 19:13:25 +0200
demerphq  wrote:

> 
> If it can be replicated on a command line then yes.
> 

It could not be replicated on the command line; I tried this, and got 10M 
unique keys :

@arsene:~$ perl -le '%h=();for (1..10_000_000) {my $session_id = join "", 
map +(0..9,"a".."z","A".."Z")[rand(10+26*2)],
1..32;$h{$session_id}=1};$v=keys %h; print $v'
1000


-- 
Bien à vous, Vincent Veyron 

https://libremen.com
Logiciels de gestion, libres

Re: random token re-used in subsequent requests [SOLVED]

[Vincent Veyron]

On Tue, 31 May 2016 18:59:46 +0200
André Warnier  wrote:

> But now you have a 32-bit machine + OS, and a 32-bit perl, right ?

now it's a 64-bit machine + OS. I use standard distribution packages for 
everything.

I installed qemu-kvm and created a 32-bit VM guest on it to try and reproduce 
the problem, unsuccessfully.

> The problem before happened on a 64-bit machine, with a 64-bit OS, but a 
> 32-bit perl, no ?
> 

It was the same 64-bit machine, installed with a 32-bit OS (Debian i386); using 
system Perl and distribution packages for Apache/mod_perl, so I assume 
everything was 32-bit

I just found this in the Debian docs 
(https://www.debian.org/releases/stable/i386/ch02s01.html.en#idp64260288) :

"If your system has a 64-bit processor from the AMD64 or Intel 64 families, you 
will probably want to use the installer for the amd64 architecture instead of 
the installer for the (32-bit) i386 architecture."

So, maybe it was not a good idea?

-- 
Bien à vous, Vincent Veyron 

https://marica.fr/
Gestion des sinistres assurance et des dossiers contentieux pour le service 
juridique

Re: random token re-used in subsequent requests [SOLVED]

[demerphq]

On 27 May 2016 at 09:29, André Warnier  wrote:
> On 26.05.2016 16:01, Vincent Veyron wrote:
>>
>> On Mon, 16 May 2016 16:38:18 +0200
>> Vincent Veyron  wrote:
>>
>>> Out of five different servers, the code works fine on four machines, and
>>> a different token is generated every time the page is loaded or re-loaded.
>>> On one server however, a previous token is being re-used
>>
>>
>> Hi,
>>
>> The faulty server was installed with 32-bit binaries on a 64-bit
>> processor.
>>
>> I did a clean re-install using 64-bit binaries (debian stable AMD64), and
>> the problem went away.
>>
>> ab -n 2 -c 5 ""
>>
>> now generates 2 unique keys.
>>
>> Speed also increased from 40 to 70 pages/second
>>
>
> Thanks for reporting this.
>
> The above strongly hints at some flaw in the srand() of perl, when called by
> a 32-bit perl, on a 64-bit OS/machine.
> In the course of this discussion, I remember citing some article found on
> the web, which was talking about something along those lines (such as the
> fact that only the lower or upper 32 bits were being used or so).
> Maybe it is worth passing this info along to the perl (language) developers,
> at www.perl.org ?

If it can be replicated on a command line then yes.

But you will want to send the bug report to perl...@perl.org

FWIW, if your perl is sufficiently late we use the BSD implementation
of DRAND48, so we definitely would like to know if you find an issue.

Yves (who is a perl5porter)


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: random token re-used in subsequent requests [SOLVED]

[André Warnier]

On 31.05.2016 18:40, Vincent Veyron wrote:

On Fri, 27 May 2016 09:29:36 +0200
André Warnier  wrote:



The above strongly hints at some flaw in the srand() of perl, when called by a 
32-bit
perl, on a 64-bit OS/machine.
Maybe it is worth passing this info along to the perl (language) developers, at 
www.perl.org ?



Sorry for the delay getting back to you : since I wiped and re-installed the 
machine, I created a virtual machine with a 32bit image, so that took a little 
time. And, guess what? I can't reproduce the problem in the VM.

Also, it only appeared in mod_perl, not perl.

The bug may have to do with a cpan upgrade I did on the machine, that generated 
quite a bit of errors, and messed my system somehow.



Thanks for the feedback.
But now you have a 32-bit machine + OS, and a 32-bit perl, right ?
The problem before happened on a 64-bit machine, with a 64-bit OS, but a 32-bit 
perl, no ?

Re: random token re-used in subsequent requests [SOLVED]

[Vincent Veyron]

On Fri, 27 May 2016 09:29:36 +0200
André Warnier  wrote:

> 
> The above strongly hints at some flaw in the srand() of perl, when called by 
> a 32-bit 
> perl, on a 64-bit OS/machine.
> Maybe it is worth passing this info along to the perl (language) developers, 
> at www.perl.org ?
> 

Sorry for the delay getting back to you : since I wiped and re-installed the 
machine, I created a virtual machine with a 32bit image, so that took a little 
time. And, guess what? I can't reproduce the problem in the VM. 

Also, it only appeared in mod_perl, not perl.

The bug may have to do with a cpan upgrade I did on the machine, that generated 
quite a bit of errors, and messed my system somehow. 

-- 
Bien à vous, Vincent Veyron 

https://compta.libremen.com
Logiciel libre de comptabilité générale

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

On Tue, May 31, 2016 at 7:35 AM, William A Rowe Jr 
wrote:

> On May 29, 2016 01:02, "Jie Gao"  wrote:
> >
> > Hi All
> >
> > I wonder if anybody is looking at this issue. At the moment, the build
> cores even at the end of generating a Makefile.
> >
> > If not, I would like to get my hands dirty in an attmpt to get the ball
> rolling. Any help on how to get a handle on the "ip comparisons"
> recommended by W. Rowe Jr would be much appreciated.
>
> Hi Jie,
>
> At the moment, I'm still on the fence of whether this is a supportable use
> case (in the faux-handler for the modperl alt protocol example.)
>
> If it is not, the fix is to drop the test from modperl.
>

Alternately, the test could be fixed, but that is non-trivial...

A non-request oriented alt protocol simply never examines the req_rec,
and must not use request oriented modules like auth.  That should be
pretty obvious.

To create a pseudo -request- handler, you would have your connection
hook handler populate the appropriate fields and insert the appropriate
protocol-specific input and output filters below the request/body filters
and run the request through the rest of the phases, performing the
auth validation at the appropriate phase of the request (post_read
would be one obvious choice.)

Otherwise, the fix is also straightforward, I can provide hints, but you
> can cause the fault by changing the domain name in the test case config
> from example 'hostname' to example 'ip addr'.  The offending code is in the
> backtrace.  Both ip and host lookups would test if the useragent_addr is
> null, and use the corresponding lookups from the conn_rec.
>
> I sort of expect the modperl test to continue to be broken because the
> req_rec simply has not been fully initialized... it is not until the entire
> read_req hook phase is complete that all these req_rec field members have
> meaningful values.
>
> But if enough folks agree we can fix the lookup to refer to the conn_rec
> values until useragent_addr is initialized.
>

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

On May 29, 2016 01:02, "Jie Gao"  wrote:
>
> Hi All
>
> I wonder if anybody is looking at this issue. At the moment, the build
cores even at the end of generating a Makefile.
>
> If not, I would like to get my hands dirty in an attmpt to get the ball
rolling. Any help on how to get a handle on the "ip comparisons"
recommended by W. Rowe Jr would be much appreciated.

Hi Jie,

At the moment, I'm still on the fence of whether this is a supportable use
case (in the faux-handler for the modperl alt protocol example.)

If it is not, the fix is to drop the test from modperl.

Otherwise, the fix is also straightforward, I can provide hints, but you
can cause the fault by changing the domain name in the test case config
from example 'hostname' to example 'ip addr'.  The offending code is in the
backtrace.  Both ip and host lookups would test if the useragent_addr is
null, and use the corresponding lookups from the conn_rec.

I sort of expect the modperl test to continue to be broken because the
req_rec simply has not been fully initialized... it is not until the entire
read_req hook phase is complete that all these req_rec field members have
meaningful values.

But if enough folks agree we can fix the lookup to refer to the conn_rec
values until useragent_addr is initialized.