Re: [Full-disclosure] NMAP Vulnerable to attack
How ironic... On Fri, Sep 10, 2010 at 11:07 PM, wrote: > On Fri, 10 Sep 2010 22:52:46 +0200, Stefano Angaran said: > > > I think that was a joke > > You're new here, aren't you? :) > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > -- HONEY: I want to… put some powder on my nose. GEORGE: Martha, won’t you show her where we keep the euphemism? ___ 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] [ MDVSA-2010:174 ] quagga
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2010:174 http://www.mandriva.com/security/ ___ Package : quagga Date: September 11, 2010 Affected: Corporate 4.0 ___ Problem Description: Stack-based buffer overflow in the bgp_route_refresh_receive function in bgp_packet.c in bgpd in Quagga before 0.99.17 allows remote authenticated users to cause a denial of service (daemon crash) or possibly execute arbitrary code via a malformed Outbound Route Filtering (ORF) record in a BGP ROUTE-REFRESH (RR) message (CVE-2010-2948). bgpd in Quagga before 0.99.17 does not properly parse AS paths, which allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via an unknown AS type in an AS path attribute in a BGP UPDATE message (CVE-2010-2949). Updated packages are available that bring Quagga to version 0.99.17 which provides numerous bugfixes over the previous 0.99.12 version, and also corrects these issues. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2948 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2949 ___ Updated Packages: Corporate 4.0: 982061c8bac57d5878a2dbd9747234f4 corporate/4.0/i586/libquagga0-0.99.17-0.1.20060mlcs4.i586.rpm 53b1e909e046539dcfd55f9b1f62e7ea corporate/4.0/i586/libquagga0-devel-0.99.17-0.1.20060mlcs4.i586.rpm 796ef3f10f793f6546ce6a0525082fa5 corporate/4.0/i586/quagga-0.99.17-0.1.20060mlcs4.i586.rpm 423c4032225687b252ddb3887db1f226 corporate/4.0/i586/quagga-contrib-0.99.17-0.1.20060mlcs4.i586.rpm 9f63365fc185a7bdf930a80cb6615c7d corporate/4.0/SRPMS/quagga-0.99.17-0.1.20060mlcs4.src.rpm Corporate 4.0/X86_64: 9b36814efd0751aa81e38baec0d2bae6 corporate/4.0/x86_64/lib64quagga0-0.99.17-0.1.20060mlcs4.x86_64.rpm 64ab6ba845a97236ffd2898e0aef892d corporate/4.0/x86_64/lib64quagga0-devel-0.99.17-0.1.20060mlcs4.x86_64.rpm 7d259ae75e30e1d172e340cc232d1ff2 corporate/4.0/x86_64/quagga-0.99.17-0.1.20060mlcs4.x86_64.rpm 2f3390db2bae0e0d505ec759e0a15232 corporate/4.0/x86_64/quagga-contrib-0.99.17-0.1.20060mlcs4.x86_64.rpm 9f63365fc185a7bdf930a80cb6615c7d corporate/4.0/SRPMS/quagga-0.99.17-0.1.20060mlcs4.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFMi592mqjQ0CJFipgRAoHFAJ0XDJVqB+SJmOHZ0hrPlMgjTMYeNgCgwxRw AMo+uyGwHeG+uyLmOzKKMOs= =ahfH -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Nmap NOT VULNERABLE to Windows DLL Hijacking Vulnerability
>> A lot of black hats will intentionally launch a whole mess of > nmap and nessus scans from zillions of throw-away zombies, just so their > *real* > attack can fly under the wire. > Totally agree. Intrusion attempts, port scanning, ..etc takes place all the time in Internet space. Who really cares? Tools such as - idswakeup - inundator - ownsnort have been round for a while. ___ 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] NMAP Vulnerable to attack
Yeah, it's an intentional JOKE to MustLive who's been posting web stuffs. ___ 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] Nmap NOT VULNERABLE to Windows DLL Hijacking Vulnerability
On Sat, 11 Sep 2010 18:32:31 +0530, jai said: > NMAP is detected by Snort and othr IDS, is not possible to have fool proof You *do* realize that out in the real world, an NMAP scan is very likely to not actually be noticed and cared about, right? If you got a security analyst out of bed every time Snort detected an nmap scan at 3AM, very soon you'll have a sleep-deprived analyst who won't be worth shit when a *real* attack happens. Often, you can use that "this attack is detected" feature against the site under attack. A lot of black hats will intentionally launch a whole mess of nmap and nessus scans from zillions of throw-away zombies, just so their *real* attack can fly under the wire. pgp3ymUa2jek1.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/
Re: [Full-disclosure] Nmap NOT VULNERABLE to Windows DLL Hijacking Vulnerability
Dear Fyodor, NMAP is detected by Snort and othr IDS, is not possible to have fool proof ~j. On 9/11/10, Fyodor wrote: > > On Fri, Sep 10, 2010 at 02:08:14PM -0400, Dan Kaminsky wrote: > > > > Frankly, I think we can find better bugs. I think we'd better. Just > > like bad money drives out good money, bad bugs drive out good bugs. > > The credibility of advisories, and even the usefulness of FD, is > > somewhat at risk. > > Hi Dan. You make good points, like usual. I just want to comment on > one aspect: > > > So we're on the cusp of some huge portion of advisories coming from > > the security community being little more than "random Windows app > > runs DLLs from CWD". > > Another problem with this is that it is the way Windows was > intentionally designed and documented to operate :/. Apps like Nmap > don't know where (for example) Winpcap's DLLs are installed on a given > system, so we rely on the operating system to locate and load them > securely. Most operating systems do this properly, and it isn't very > hard. You just need a library search path which only contains system > directories that potential attackers can't write to. > > Microsoft, on the other hand, intentionally decided to include the > current working directory in that search path. Up until XP SP2, they > even gave DLLs in CWD priority over those in system directories! Then > MS introduced "SafeDllSearchMode", which is now enabled by default. > This SHOULD HAVE removed CWD from the library search path entirely, > but instead Microsoft just shifted the search order around so that CWD > is searched later :(. > > Now Microsoft has added a new hack, calling SetDllDirectory() with the > empty string, which actually DOES remove CWD from the search path if > you are running a recent enough version of Windows. But many/most > apps won't even know to call that. The search path should be secure > by default (especially when things like "SafeDllSearchMode" are set), > and apps or users should have to add CWD themselves if they really > want it included. > > So rather than have advisories for every application which honors the > default Windows DLL search path, I hope someone can convince MS to > make their search path secure by default (remove potentially untrusted > dirs like CWD). Linux/Unix users would have the same vulnerabilities > if they did something dumb like add CWD to their LD_LIBRARY_PATH, but > at least their vendors don't ship it that way! > > And while anyone is bugging MS about the DLL search path, please ask > MS to re-enable raw sockets too :). > > Cheers, > Fyodor > > ___ > 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] Nmap NOT VULNERABLE to Windows DLL Hijacking Vulnerability
On Fri, Sep 10, 2010 at 02:08:14PM -0400, Dan Kaminsky wrote: > > Frankly, I think we can find better bugs. I think we'd better. Just > like bad money drives out good money, bad bugs drive out good bugs. > The credibility of advisories, and even the usefulness of FD, is > somewhat at risk. Hi Dan. You make good points, like usual. I just want to comment on one aspect: > So we're on the cusp of some huge portion of advisories coming from > the security community being little more than "random Windows app > runs DLLs from CWD". Another problem with this is that it is the way Windows was intentionally designed and documented to operate :/. Apps like Nmap don't know where (for example) Winpcap's DLLs are installed on a given system, so we rely on the operating system to locate and load them securely. Most operating systems do this properly, and it isn't very hard. You just need a library search path which only contains system directories that potential attackers can't write to. Microsoft, on the other hand, intentionally decided to include the current working directory in that search path. Up until XP SP2, they even gave DLLs in CWD priority over those in system directories! Then MS introduced "SafeDllSearchMode", which is now enabled by default. This SHOULD HAVE removed CWD from the library search path entirely, but instead Microsoft just shifted the search order around so that CWD is searched later :(. Now Microsoft has added a new hack, calling SetDllDirectory() with the empty string, which actually DOES remove CWD from the search path if you are running a recent enough version of Windows. But many/most apps won't even know to call that. The search path should be secure by default (especially when things like "SafeDllSearchMode" are set), and apps or users should have to add CWD themselves if they really want it included. So rather than have advisories for every application which honors the default Windows DLL search path, I hope someone can convince MS to make their search path secure by default (remove potentially untrusted dirs like CWD). Linux/Unix users would have the same vulnerabilities if they did something dumb like add CWD to their LD_LIBRARY_PATH, but at least their vendors don't ship it that way! And while anyone is bugging MS about the DLL search path, please ask MS to re-enable raw sockets too :). Cheers, Fyodor ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
