Date: Thu, 27 Oct 2011 11:26:11 -0400 (EDT)
From: bugs@....dhs.org
To: "Benjamin Renaut" <benml@...idev.fr>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Symlink vulnerabilities

> Thanks !
>
> Mine is definitely not more refined, it simply does the same ;-)
> the only advantage I see is that it's written in C and will probably run
> faster - giving it more chances of success.

Yes, I suspect your success rate will be much better than mine. =-)


>
> On 27/10/11 17:12, bugs@....dhs.org wrote:
>> my notes/exploit:
>>
>> http://www.downspout.org/?q=node/7
>>
>> I am sure yours is more refined than mine.
>>
>>> I just wrote a quick PoC for this (warning: didn't test the code a
>>> lot):
>>>
>>> http://pastebin.com/FaaEsXRW
>>>
>>> (compile that with -O3).
>>> successfully tried it on my machine (Debian stable, amd64, high-end
>>> laptop).
>>> It probably has more chances of success on low-end hardware, or if the
>>> system is busy.
>>>
>>> If you really really want it to work the first time, bzexe a binary
>>> (say, ls) and then open the resulting file.
>>> Increment the value of the "skip" variable at the top and add:
>>>
>>> sleep 1
>>>
>>> right after the "/bin/ln $tmpfile..." line. This will slow down the
>>> bzexe shell script so the flaw is more visible.
>>>
>>> The example shellcode in the PoC will simply execute "id" and write the
>>> output into /tmp/stdout.bzexe_poc.
>>>
>>> Note that this'll work not only with root: you can execute something
>>> with the rights of any user launching a bzexe-d binary (as long as you
>>> know what they're gonna run beforehand).
>>>
>>> Regards,
>>> Benjamin Renaut.
>>>
>>> On 27/10/11 16:08, Benjamin Renaut wrote:
>>>> Imagine the following scenario:
>>>>
>>>> - You create /tmp/<prog name>   (a directory)
>>>> - Root is launching a bzexe-d binary (<prog name>).
>>>> - The ln done by bzexe results in the link being created inside
>>>> /tmp/<prog name>   (your directory), as explained by Vlad.
>>>> - Before the bzexe shell script executes /tmp/<prog name>, you remove
>>>> your directory (/tmp/<prog name>) and replace it by an evil shell
>>>> script.
>>>> - The bzexe shell code executes *your* shell script, with root rights.
>>>>
>>>> =>   So *yes*, this seems exploitable, given the following
>>>> requirement:
>>>> root has to execute a bzexe binary and you have to know it beforehand.
>>>>
>>>> The race condition if a little hard to exploit but it's doable.
>>>>
>>>> As for a POC, just add some sleep commands inside the bzexe shell
>>>> script
>>>> and it becomes easy to prove.
>>>>
>>>> On 27/10/11 15:43, xD 0x41 wrote:
>>>>> Vlad,
>>>>>        I wont repeat myself, again, your PoC will NOT work.
>>>>> it will NOT get root anything!
>>>>> please, understand it, and maybe, make a working poc, then see why...
>>>>> It was shown clearly by 2 people or more that, it cannot work.
>>>>> If you can do better, and, sure, do what you said wich is exact area
>>>>> where it wont listen tho... wich is here:
>>>>>
>>>>> This means that right after the "ln" command AND before "/tmp/dd" is
>>>>> launched, the user can replace the directory "/tmp/dd" by a shell
>>>>> script
>>>>> with the same name ("/tmp/dd").
>>>>>
>>>>> You try to change and fiddle here, it would need alot better than
>>>>> just
>>>>> the current shell scripting, and, even then, i dnt think it would win
>>>>> the race conditiobn.
>>>>> I have made a poc, i know atleast 2 others have, and, I guess those
>>>>> people have already shown where it goes wrong for them and, it is no
>>>>> different, because, for whatever reason, if you say it is not aslr,
>>>>> thats fine... but, i am just saying what my opinion is.
>>>>> You can dream all you want about this being so leet but, dude, they
>>>>> would have bothered to patch it, if indeed it led to anything *root*
>>>>> or pwnage, wich is when they suually act.
>>>>> So, I know for fact, there is easier methods than this to be had, and
>>>>> telling you, am very experinced with these scripts, and this
>>>>> particular one, i wanted to use, ofcourse, to root some kernels!
>>>>> Hell,
>>>>> i am a blackhat...so, i wanted to remake but, nothing, and when
>>>>> exchanged notes on it, I got nothing but told, aslr/memory will shut
>>>>> it down, etc etc..  but, i stfu and kept writing my poc, then, when i
>>>>> thought it was perfect, it would not allow me to occupy that space,
>>>>> maybe if i could be bothered to occupy the EIP or, overwrite it
>>>>> somehow, then i would perhaps bother for race, but seriusly in the
>>>>> form your saying, well, hey, kets just tar anything, and, rely on the
>>>>> internals to fail...surely this would never give us root...
>>>>>
>>>>>
>>>>> as i said.. you dont need to even look as far as you are, but, this
>>>>> is
>>>>> a flawed and, sorry but, it is prroven to fail.
>>>>> if it were any decent, like kcopes sh scripts usually are, then, it
>>>>> would be PATHCED :)
>>>>> Sorry, no banana i said :)
>>>>> I mean it.
>>>>> you will NOT make any PoC here in bash script.
>>>>> Sorry, but, get out of those delusional state, and, skip to real
>>>>> world, it is 2011, and it is vanilllllla :)
>>>>> anyhow, have a good day but, please, i have said and prooven whatever
>>>>> i wanted, so, i dont need any more tech talk, it is a failed poc,
>>>>> when
>>>>> u will understand even how secteams like ubuntu work, then maybe, you
>>>>> will see that, it is indeed flawed and, thus de prioritised and face
>>>>> it, i know many hax0rs and, they never once mentioned it, and believe
>>>>> me, they sfrape these lists with 3x finetooth combs :P
>>>>> This is NOT HAPPENIN!
>>>>> Ok, that is enough now, have a nice day, and, no, i dont want any
>>>>> replys saying how "yes yes but it can thru this and that..." , coz,
>>>>> IT
>>>>> CANT so please, have a nice day, and, go read up on git or
>>>>> sumthin...do sumthin useful, your wasting time pushing on a dead
>>>>> pioc.
>>>>> either fkn make it properly, or stfu and simply accept it cannot b
>>>>> done, now, i know howmany lines it took me, and, if you cannot make
>>>>> the failure poc wich you outlined, then, id be dissapintedm, as
>>>>> someone alredy has done, exactly what you did, and, showed it
>>>>> executing, and FAILING.
>>>>> That was end of it for the whole list i believe.
>>>>> A poc, wich was perfectly coded to meet your standards, and, it
>>>>> failed
>>>>> dude. you cannot just chmod any file and make it *suid*... seriously,
>>>>> whatever ebooks your reading (GNY??) get off them, theyre bad for
>>>>> your
>>>>> health like nicotine is to me :)
>>>>> ciao baby
>>>>> xdab
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 27 October 2011 06:31, vladz<vladz@...zero.fr>    wrote:
>>>>>> This vulnerability is trivial and I don't even know why it is making
>>>>>> so
>>>>>> much noises as bzexe is almost never used and the exploit would only
>>>>>> work under certain circumstances.  It quoted it because it was an
>>>>>> example of insecure uses of "/tmp", thats all!
>>>>>>
>>>>>> Note for "xD 0x41":  before you say something about "ASLR", know
>>>>>> that
>>>>>> it
>>>>>> has nothing to see with it.
>>>>>>
>>>>>> I will explain it shortly (even if Tavis was very clear), and hope
>>>>>> this
>>>>>> will end this conversation! lol
>>>>>>
>>>>>> Imagine the "dd" command has been compressed by root using bzexe:
>>>>>>
>>>>>>     # bzexe /bin/dd
>>>>>>       /bin/dd:  1.996:1,  4.008 bits/byte, 49.90% saved, 49168 in,
>>>>>> 24635 out.
>>>>>>
>>>>>>     # ls -l /bin/dd*
>>>>>>     -rwxr-xr-x 1 root root 25286 26 oct.  20:38 /bin/dd
>>>>>>     -rwxr-xr-x 1 root root 49168 28 avril  2010 /bin/dd~
>>>>>>
>>>>>>     # cat -n /bin/dd | head -15
>>>>>>          1        #!/bin/sh
>>>>>>         [...]
>>>>>>         10          prog="`echo $0 | /bin/sed 's|^.*/||'`"
>>>>>>         11          if /bin/ln $tmpfile "/tmp/$prog" 2>/dev/null;
>>>>>> then
>>>>>>         12            trap '/bin/rm -f $tmpfile "/tmp/$prog"; exit
>>>>>> $res' 0
>>>>>>         13            (/bin/sleep 5; /bin/rm -f $tmpfile
>>>>>> "/tmp/$prog")
>>>>>> 2>/dev/null&
>>>>>>         14            /tmp/"$prog" ${1+"$@"}; res=$?
>>>>>>         [...]
>>>>>>
>>>>>> If a user creates a directory "/tmp/dd", look what happens when root
>>>>>> calls "dd":
>>>>>>
>>>>>>     # bash -x /bin/dd
>>>>>>     [...]
>>>>>>     + /usr/bin/tail -n +23 /bin/dd
>>>>>>     + umask 0022
>>>>>>     + /bin/chmod 700 /tmp/gztmpIfsTrk
>>>>>>     ++ /bin/sed 's|^.*/||'
>>>>>>     ++ echo /bin/dd
>>>>>>     + prog=dd
>>>>>>     + /bin/ln /tmp/gztmpIfsTrk /tmp/dd<<    ln succeeded!
>>>>>>     + trap '/bin/rm -f $tmpfile "/tmp/$prog"; exit $res' 0
>>>>>>     + /tmp/dd<<    /tmp/dd is launched!
>>>>>>     /bin/dd: line 14: /tmp/dd: is a directory
>>>>>>
>>>>>> This means that right after the "ln" command AND before "/tmp/dd" is
>>>>>> launched, the user can replace the directory "/tmp/dd" by a shell
>>>>>> script
>>>>>> with the same name ("/tmp/dd").
>>>>>>
>>>>>> Is this clear enough?
>>>>>>
>>>>>> Cheers,
>>>>>> vladz.
>>>>>> --
>>>>>> http://vladz.devzero.fr
>>>>>> PGP key 8F7E2D3C from pgp.mit.edu
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 25, 2011 at 08:42:38PM -0400, bugs@....dhs.org wrote:
>>>>>>> Aw, Even if you loop and copy a binary continuously into that
>>>>>>> directory
>>>>>>> say bash is bzexe'd.
>>>>>>>
>>>>>>> and our exploit does the following
>>>>>>>
>>>>>>> #!/bin/sh
>>>>>>> chmod 777 /etc/shadow
>>>>>>>
>>>>>>> You'll get,
>>>>>>>
>>>>>>> kemical:~# bzexe bash
>>>>>>>      bash:     2.214:1,  3.614 bits/byte, 54.83% saved, 700492 in,
>>>>>>> 316442 out.
>>>>>>> kemical:~# ./bash
>>>>>>> ./bash: line 14: /tmp/bash: is a directory
>>>>>>> /bin/rm: cannot remove `/tmp/bash': Is a directory
>>>>>>>
>>>>>>> kemical:~# ls -l /etc/shadow
>>>>>>> -rw-r----- 1 root shadow 1174 2010-12-07 16:49 /etc/shadow
>>>>>>>
>>>>>>>
>>>>>>> + /bin/rm -f /tmp/gztmpYCf11e /tmp/bash
>>>>>>> /bin/rm: cannot remove `/tmp/bash': Is a directory
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA256
>>>>>>>>
>>>>>>>> Race condition != Memory corruption...
>>>>>>>>
>>>>>>>> (and therefore ASLR has NOTHING to do with it...)
>>>>>>>>
>>>>>>>> http://i.imgur.com/l1l3o.gif<= me after reading this.
>>>>>>>>
>>>>>>>> On 10/25/2011 06:56 PM, xD 0x41 wrote:
>>>>>>>>> ln actually succeeds, but created /tmp/foo/foo instead. The
>>>>>>>>> attacker
>>>>>>>>> still
>>>>>>>>> owns /tmp/foo, so he quickly rename()s it and replaces /tmp/foo
>>>>>>>>> with his
>>>>>>>>> exploit.
>>>>>>>>>
>>>>>>>>> You can make it bypass Aslr ?
>>>>>>>>> This is what im talking about tavis, not the well known ln and
>>>>>>>>> other
>>>>>>>>> bugs you have pleasured us all with :)
>>>>>>>>> THIS one, cannot be won.
>>>>>>>>> proove it, it is a shitty poc, i cannot get passed the break when
>>>>>>>>> it
>>>>>>>>> symlinks across using ln, it triggers something, and shuts
>>>>>>>>> whatever
>>>>>>>>> down..
>>>>>>>>> Your audit and kcopes audit bugs, work alittle differently..
>>>>>>>>> This PoC is a *fail* Tavis, you would otherwise have made it into
>>>>>>>>> a
>>>>>>>>> real
>>>>>>>>> poc that actually spawns root , yes even in cron if what your
>>>>>>>>> saying is
>>>>>>>>> right , no?
>>>>>>>>> Im saying, Kernel will shut your PoC down, your saying it wont.
>>>>>>>>> Proove me wrong , coz sofar, many have tried and many have
>>>>>>>>> failed.
>>>>>>>>> it does not even need be disclosed, i dont mind.
>>>>>>>>> i would be happy thelp fix a bug within the kernel but, we both
>>>>>>>>> know
>>>>>>>>> this is not within kernel land,it is a bug in another area,
>>>>>>>>> It still must bypass atleast ASLR on vanilla to be called a real
>>>>>>>>> poc,and
>>>>>>>>> be treated as such by the secteam of Ubuntu and debian, of wich,
>>>>>>>>> they
>>>>>>>>> dont seem to be in any hurry atall about this one, where, your
>>>>>>>>> ones, and
>>>>>>>>> kcopes, they were VERY prompt to jump on.
>>>>>>>>> i believe many have recreated it, but simply cannnot get it to
>>>>>>>>> spawn a
>>>>>>>>> stable enough root shell.
>>>>>>>>> Your the brains in bash, i wont deny you this, but i do not se
>>>>>>>>> this
>>>>>>>>> one
>>>>>>>>> working Tavis :s
>>>>>>>>> Please, by all means, proove it and Vladz name is clear.
>>>>>>>>> Otherwise
>>>>>>>>> to me
>>>>>>>>> is just another exposed failed poc wich is screaming for ubuntu
>>>>>>>>> devteam
>>>>>>>>> to give a crap :s.
>>>>>>>>> My outlook is bleak, yes, but i was part of one of such teams
>>>>>>>>> years
>>>>>>>>> ago,
>>>>>>>>> altho, i wont go into that now, it is not even part of this OS,
>>>>>>>>> so,
>>>>>>>>> I do
>>>>>>>>> know how secteams somewhat work, they prioritise things.
>>>>>>>>> if a bug is being used like crazy to exploit, they will simply
>>>>>>>>> implant
>>>>>>>>> some new binarys, along with theyre kernel..and possibly update
>>>>>>>>> bzexe
>>>>>>>>> and bunzip etc, all of wich have had many flaws, i just dont
>>>>>>>>> think
>>>>>>>>> a
>>>>>>>>> race condition can be won in this case.
>>>>>>>>> Thats from actual hard code exploits not running because of aslr,
>>>>>>>>> on the
>>>>>>>>> simplest of setups even.
>>>>>>>>> Its already out, this infos, so, if you think it also leads to
>>>>>>>>> root,
>>>>>>>>> then i would expect YOU of all people to be alot more proactive
>>>>>>>>> about
>>>>>>>>> it.
>>>>>>>>> Your not though.
>>>>>>>>> I appreciate the time you have taken but, i believe you wont win
>>>>>>>>> this
>>>>>>>>> race :).
>>>>>>>>> Have a nice day.
>>>>>>>>> xd
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 25 October 2011 21:06, Tavis Ormandy<taviso@...xchg8b.com
>>>>>>>>> <mailto:taviso@...xchg8b.com>>    wrote:
>>>>>>>>>
>>>>>>>>>        xD 0x41<secn3t@...il.com<mailto:secn3t@...il.com>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>        >    Hello,
>>>>>>>>>        >         Your 'race condition possibly leading to root'is
>>>>>>>>> a
>>>>>>>>> myth...
>>>>>>>>>        >    Yes thats maybe because race condition or not, it is
>>>>>>>>> ASLR
>>>>>>>>> wich
>>>>>>>>> will
>>>>>>>>>        >    prevent from ANY rootshell,and Yes, it has bveen
>>>>>>>>> tried...
>>>>>>>>> You can
>>>>>>>>> do
>>>>>>>>>        >    better, go right ahed ;-) I am betting you thats why
>>>>>>>>> it
>>>>>>>>> aint being
>>>>>>>>>        ptached
>>>>>>>>>        >    in any hurry, because obv if you read some notes
>>>>>>>>> about it
>>>>>>>>> in the
>>>>>>>>>        committs,
>>>>>>>>>        >    you will see they must have reproduced the said bugs,
>>>>>>>>> in
>>>>>>>>> and with,
>>>>>>>>>        more
>>>>>>>>>        >    than JUST bzexe even... but anyhow, your PoC is bs.
>>>>>>>>>
>>>>>>>>>        I think you misunderstood, he's not talking about memory
>>>>>>>>> corruption,
>>>>>>>>> his
>>>>>>>>>        attack sounds like a legitimate filesystem race. I'll try
>>>>>>>>> to
>>>>>>>>>        explain, the
>>>>>>>>>        bzexe utility compresses executables and then decompresses
>>>>>>>>> them at
>>>>>>>>>        runtime
>>>>>>>>>        by prepending a decompression stub.
>>>>>>>>>
>>>>>>>>>        His attack is against the stub, which is a bourne shell
>>>>>>>>> script. It
>>>>>>>>>        basically
>>>>>>>>>        does this:
>>>>>>>>>
>>>>>>>>>           1. Safely decompress the original executable inside
>>>>>>>>> /tmp
>>>>>>>>> using
>>>>>>>>>        tempfile.
>>>>>>>>>           2. Create a hardlink to the decompressed executable
>>>>>>>>> with
>>>>>>>>> the same
>>>>>>>>>        name
>>>>>>>>>        of the original input (this is a trick to maintain
>>>>>>>>> argv[0],
>>>>>>>>> which is
>>>>>>>>>        not as
>>>>>>>>>        easy in bourne as it is in modern shells).
>>>>>>>>>           3. Execute the hardlink with the requested parameters.
>>>>>>>>>
>>>>>>>>>        His attack is against stage 2, he points out that although
>>>>>>>>> it
>>>>>>>>> is
>>>>>>>>>        safe to use
>>>>>>>>>        the link() system call in /tmp, the ln(1) utility does
>>>>>>>>> some
>>>>>>>>> convenience
>>>>>>>>>        processing if you pass it a directory name.
>>>>>>>>>
>>>>>>>>>        So, the attack scenario would be that root executed a
>>>>>>>>> bzexe
>>>>>>>>> compressed
>>>>>>>>>        executable called foo, and then he creates the directory
>>>>>>>>> /tmp/foo,
>>>>>>>>>        and makes
>>>>>>>>>        it 777.
>>>>>>>>>
>>>>>>>>>        ln actually succeeds, but created /tmp/foo/foo instead.
>>>>>>>>> The
>>>>>>>>> attacker
>>>>>>>>>        still
>>>>>>>>>        owns /tmp/foo, so he quickly rename()s it and replaces
>>>>>>>>> /tmp/foo with
>>>>>>>>> his
>>>>>>>>>        exploit.
>>>>>>>>>
>>>>>>>>>        Now root executes it, and gives him a root shell.
>>>>>>>>>
>>>>>>>>>        Vladz suggests using -F, which will solve this problem by
>>>>>>>>> telling ln
>>>>>>>>>        to use
>>>>>>>>>        the directory name instead. This will work nicely.
>>>>>>>>>
>>>>>>>>>        >    Make it then ill
>>>>>>>>>        >    believe it, ask others, you wont beat aslr on even
>>>>>>>>> vanilla,. So,
>>>>>>>>> stop
>>>>>>>>>        >    complaining you did not get into patch- halll of
>>>>>>>>> flame..
>>>>>>>>> it was
>>>>>>>>>        not really
>>>>>>>>>        >    going to be ever exploited, or you would surely not
>>>>>>>>> be
>>>>>>>>> the one
>>>>>>>>> posting
>>>>>>>>>        >    this ;) Anyhow, nice try but no banana. xd
>>>>>>>>>
>>>>>>>>>        I think it's quite a nice example, and a nice simple
>>>>>>>>> solution.
>>>>>>>>> Imagine a
>>>>>>>>>        system where crond executes a bzexe utility at regular
>>>>>>>>> intervals,
>>>>>>>>> Vladz'
>>>>>>>>>        attack will eventually succeed.
>>>>>>>>>
>>>>>>>>>        Tavis.
>>>>>>>>>
>>>>>>>>>        >
>>>>>>>>>        >
>>>>>>>>>        >    On 24 October 2011 05:55, vladz<vladz@...zero.fr
>>>>>>>>>        <mailto:vladz@...zero.fr>>    wrote:
>>>>>>>>>        >
>>>>>>>>>        >    >    On Fri, Oct 21, 2011 at 07:59:59PM -0400,
>>>>>>>>> bugs@....dhs.org
>>>>>>>>>        <mailto:bugs@....dhs.org>    wrote:
>>>>>>>>>        >    >    >    bzexe utility:
>>>>>>>>>        >    >    >
>>>>>>>>>        >    >    >    /bin/bzexe:tmp=gz$$ /bin/bzexe:rm -f
>>>>>>>>> zfoo[12]$$
>>>>>>>>>        >    >
>>>>>>>>>        >    >    I reported this one several months ago (in some
>>>>>>>>> conditions it
>>>>>>>>>        could lead
>>>>>>>>>        >    >    to a root exploit) and provided an easy
>>>>>>>>> solution, but
>>>>>>>>> no
>>>>>>>>> updates:
>>>>>>>>>        >    >
>>>>>>>>>        >    >      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632862
>>>>>>>>>        >    >
>>>>>>>>>        >    >    -- http://vladz.devzero.fr PGP key 8F7E2D3C from
>>>>>>>>> pgp.mit.edu
>>>>>>>>>        <http://pgp.mit.edu>
>>>>>>>>>        >    >
>>>>>>>>>        >    >    _______________________________________________
>>>>>>>>> Full-Disclosure
>>>>>>>>> - We
>>>>>>>>>        >    >    believe in it. Charter:
>>>>>>>>>        >    >    http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>>>> Hosted and
>>>>>>>>>        >    >    sponsored by Secunia - http://secunia.com/
>>>>>>>>>        >    >
>>>>>>>>>        >
>>>>>>>>>        >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>        --
>>>>>>>>>        -------------------------------------
>>>>>>>>>        taviso@...xchg8b.com<mailto:taviso@...xchg8b.com>    | pgp
>>>>>>>>> encrypted
>>>>>>>>>        mail preferred
>>>>>>>>>        -------------------------------------------------------
>>>>>>>>>
>>>>>>>>>        _______________________________________________
>>>>>>>>>        Full-Disclosure - We believe in it.
>>>>>>>>>        Charter:
>>>>>>>>> http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>>>>        Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Full-Disclosure - We believe in it.
>>>>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>>>>>>>
>>>>>>>> iF4EAREIAAYFAk6nSXkACgkQt/95fIeU+XYT2wD8CnpWw+xUx3eGSnxCWv7LVk1a
>>>>>>>> kZgZJGQH1OdZR9uV4K8A/1BsiZ+gaDjE4Wz5L+BT56AU9XKvb4txjxVTMA8+GTna
>>>>>>>> =AD/5
>>>>>>>> -----END PGP SIGNATURE-----
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Full-Disclosure - We believe in it.
>>>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Full-Disclosure - We believe in it.
>>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>> _______________________________________________
>>>>>> Full-Disclosure - We believe in it.
>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>
>>>>> _______________________________________________
>>>>> Full-Disclosure - We believe in it.
>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>> _______________________________________________
>>>> Full-Disclosure - We believe in it.
>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists