On 1/3/07, Jim Manico [EMAIL PROTECTED] wrote:
I'm most worried about the CSRF vector.
how come?
this is client-side stuff.
--
Marcio Barbado, Jr.
==
==
___
Full-Disclosure - We believe in it.
Charter:
Ben Bucksch wrote:
Anders B Jansson wrote:
I'd say that it's a design decition, not sure that it's a design
flaw.
It's all down to what you try to protect.
... connecting any device not 100% controlled by the company to a
company network is strictly forbidden, doing so would be regarded as
Slythers Bro [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
this is a mathematic tool where all bits of a double word have 3 states :
one , zero and
unknow
i implemented the addition , multiplication (with an integer), a new
concept fusion
(equivalent to = ) , and all basic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --
Debian Security Advisory DSA 1246-1[EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
January 8th, 2007
On Sun, 07 Jan 2007 16:08:23 +0100, endrazine said:
yes that's correct but don't forget that hashes can collide
it could be the case that:
can ? could ? might ? Do you have any mathematical prouve or are you
just guessing ?
It's a pretty easy proof actually. If your password input
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-1247-1[EMAIL PROTECTED]
http://www.debian.org/security/ Noah Meyerhans
January 08, 2007
-
Hi Vladis, Hi dear list,
[EMAIL PROTECTED] a écrit :
It's a pretty easy proof actually. If your password input routine allows
more different passwords than there are possible hashes, you *will* have
collisions. For instance, if you use a 64-bit hash, and reasonable-length
passwords, you
typos :
endrazine a écrit :
Here again, I agree. Now, if one needs to exhaustively try every
possible 32b hashes with the largest possible charset (or even bigger hashes
with a smaller - like those alphanumerical keys you just mentionned), to
break a password hash, the it's not a *BIG*
rPath Security Advisory: 2007-0001-1
Published: 2007-01-08
Products: rPath Linux 1
Rating: Major
Exposure Level Classification:
Indirect User Deterministic Unauthorized Access
Updated Versions:
openoffice.org=/[EMAIL PROTECTED]:devel//1/2.0.3-1.7-1
References:
Anyone knows how this affects opensource PDF viewers like gpdf or
evince? As I understand this vulnerability, it's only effective
against embeded PDF readers, right?
A.
signature.asc
Description: Digital signature
___
Full-Disclosure - We believe in
The Anarcat wrote:
Anyone knows how this affects opensource PDF viewers like gpdf or
evince? As I understand this vulnerability, it's only effective
against embeded PDF readers, right?
I don't know what you mean embedded. It only affects Adobe Reader 7.
Matthew Flaschen
signature.asc
-- Forwarded message --
From: T Biehn [EMAIL PROTECTED]
Date: Jan 8, 2007 3:06 PM
Subject: Re: [Full-disclosure] Flog 1.1.2 Remote Admin Password Disclosure
To: endrazine [EMAIL PROTECTED]
How are you guys still arguing about this?
It wasn't even a troll.
It's called a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
___
Mandriva Linux Security Advisory MDKSA-2007:003
http://www.mandriva.com/security/
Michal Zalewski wrote:
I'd like to announce the availability of a free security reconnaissance /
firewall bypassing tool called 0trace.
Good work. Are you going to put it under a free license?
Enough chatter - the tool is available here (Linux version):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
___
Mandriva Linux Security Advisory MDKSA-2007:004
http://www.mandriva.com/security/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- ---
VMware Security Advisory
Advisory ID: VMSA-2007-0001
Synopsis: VMware ESX server security updates
Issue date:2007-01-08
Updated on:
A much easier way is to write your own usleep and drop it in /bin:
---usleep.c---
#include stdio.h
#include stdlib.h
#include unistd.h
int main (int argc, char **argv) {
usleep(atoi(argv[1]));
return 0;
}
---usleep.c---
[note: doesn't check error conditions]
0trace worked brilliantly
17 matches
Mail list logo
