| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20070130173255.0E0A6DA84C@mailserver8.hushmail.com>
Date: Tue, 30 Jan 2007 12:32:54 -0500
From: <auto458033@...hmail.com>
To: <full-disclosure@...ts.grok.org.uk>
Cc:
Subject: Re: Full-Disclosure Digest, Vol 23, Issue 56
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
ANOTHER VICTIM FALLS DEAD FROM FULL DISCLOSURE
On Tue, 30 Jan 2007 08:18:25 -0500 douglas.graham@...world.com
wrote:
>> Hello. I am Douglas Grahams Father (Roy Graham). It is with
>great regret that I have to inform you that Douglas passed away on
>the 22nd November 2006. after a very short illness. I apologise
>for the delay in letting you know, but I have only recently been
>able to access his email account.
>My wife Jacqui and I would like to thank you for assisting Douglas
>in the past and please would you remove his details from your data
>base. We hope that this email does not cause you any distress.
>Should you need to contact me my email address is:
>Braingoing@....com please enter DIGA as the subject, so that I
>know that it is not spam.
> Regards, Roy Graham
>
>> From: full-disclosure-request@...ts.grok.org.uk
>> Date: 2007/01/30 Tue PM 12:00:01 GMT
>> To: full-disclosure@...ts.grok.org.uk
>> Subject: Full-Disclosure Digest, Vol 23, Issue 56
>>
>> Send Full-Disclosure mailing list submissions to
>> full-disclosure@...ts.grok.org.uk
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.grok.org.uk/mailman/listinfo/full-disclosure
>> or, via email, send a message with subject or body 'help' to
>> full-disclosure-request@...ts.grok.org.uk
>>
>> You can reach the person managing the list at
>> full-disclosure-owner@...ts.grok.org.uk
>>
>> When replying, please edit your Subject line so it is more
>specific
>> than "Re: Contents of Full-Disclosure digest..."
>>
>>
>> Note to digest recipients - when replying to digest posts,
>please trim your post appropriately. Thank you.
>>
>>
>> Today's Topics:
>>
>> 1. CVSTrac 2.0.0 Denial of Service (DoS) vulnerability
>> (Ralf S. Engelschall)
>> 2. [OpenPKG-SA-2007.008] OpenPKG Security Advisory (cvstrac)
>> (OpenPKG GmbH)
>> 3. Oracle - Indirect Privilege Escalation and Defeating
>Virtual
>> Private Databases (David Litchfield)
>> 4. Phishing Evolution Report Released (S?nnet Beskerming)
>> 5. Universal printer provider exploit for Windows (Andres
>Tarasco)
>> 6. [DRUPAL-SA-2007-005] Drupal 4.7.6 / 5.1 fixes arbitrary
>code
>> execution issue (Uwe Hermann)
>> 7. PC/Laptop microphones (Jim Popovitch)
>> 8. Re: S21sec-034-en: Cisco VTP DoS vulnerability
>> (Clay Seaman-Kossmeyer)
>> 9. Re: PC/Laptop microphones (Tyop?)
>> 10. Re: PC/Laptop microphones (Simon Smith)
>> 11. Re: PC/Laptop microphones (Clement Dupuis)
>> 12. Re: PC/Laptop microphones (Jim Popovitch)
>> 13. Re: PC/Laptop microphones (Simon Smith)
>> 14. Re: S21sec-034-en: Cisco VTP DoS vulnerability
>> (Clay Seaman-Kossmeyer)
>> 15. COSEINC Alert: Microsoft Agent Heap Overflow Vulnerability
>> Technical Details (Patched) (COSEINC)
>>
>>
>> -----------------------------------------------------------------
>-----
>>
>> Message: 1
>> Date: Mon, 29 Jan 2007 13:27:38 +0100
>> From: "Ralf S. Engelschall" <rse@...elschall.com>
>> Subject: [Full-disclosure] CVSTrac 2.0.0 Denial of Service (DoS)
>> vulnerability
>> To: full-disclosure@...ts.grok.org.uk
>> Message-ID: <20070129122738.GA45233@...elschall.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> SECURITY ADVISORY
>> =================
>>
>> Application: CVSTrac
>> Version: 2.0.0
>> Vulnerability: Denial of Service (DoS)
>> Identification: CVE-2007-0347
>> Date: 2007-01-29 12:00 UTC
>>
>> DESCRIPTION
>> -----------
>>
>> A Denial of Service (DoS) vulnerability exists in CVSTrac
>> (http://www.cvstrac.org/) version 2.0.0, a web-based bug and
>patch-set
>> tracking system for the version control systems CVS, Subversion
>and Git.
>>
>> The vulnerability is in the Wiki-style text output formatter and
>is
>> triggered by special text constructs in commit messages, tickets
>and
>> Wiki pages. Only users with check-in permissions and Wiki or
>ticket edit
>> permissions can perform an attack. But as the anonymous user
>usually
>> is granted Wiki edit and ticket creation permissions, an
>attacker
>> remotely and anonymously can cause a partial DoS (depending on
>the pages
>> requested) on a CVSTrac installation by opening a new ticket or
>editing
>> a Wiki page with an arbitrary text containing for instance the
>string
>> "/foo/bar'quux".
>>
>> The result of an attack is an error of the underlying SQLite
>RDBMS:
>>
>> | Database Error
>> | db_exists: Database exists query failed
>> | SELECT filename FROM filechng WHERE
>filename='foo/bar'quux'
>> | Reason: near "quux": syntax error
>>
>> ANALYSIS
>> --------
>>
>> The DoS vulnerability exists because the is_eow() function in
>"format.c"
>> does NOT just check the first(!) character of the supplied
>string
>> for an End-Of-Word terminating character, but instead iterates
>over
>> string and this way can skip a single embedded quotation mark.
>The
>> is_repository_file() function then in turn assumes that the
>filename
>> string can never contain a single quotation mark and traps into
>an SQL
>> escaping problem.
>>
>> An SQL injection via this technique is somewhat limited as
>is_eow()
>> bails on whitespace. So while one _can_ do an SQL injection, one
>is
>> limited to SQL queries containing only characters which get past
>the
>> function isspace(3). This effectively limits attacks to SQL
>commands
>> like "VACUUM".
>>
>> WORKAROUND
>> ----------
>>
>> Administrators can quickly workaround by revoking permissions on
>the
>> users. Restoring those permissions, obviously, would require
>keeping
>> vulnerable permissions on at least one infrequently used account
>like
>> "setup" or using the CLI sqlite3(1) to manually add them back
>later.
>>
>> One can resurrect an attacked CVSTrac 2.0.0 by fixing the texts
>in the
>> underlying SQLite database with the following small Perl script.
>>
>> ##
>> ## cvstrack-resurrect.pl -- CVSTrac Post-Attack Database
>Resurrection
>> ## Copyright (c) 2007 Ralf S. Engelschall <rse@...elschall.com>
>> ##
>>
>> use DBI; # requires OpenPKG perl-dbi
>> use DBD::SQLite; # requires OpenPKG perl-dbi, perl-
>dbi::with_dbd_sqlite=yes
>> use DBIx::Simple; # requires OpenPKG perl-dbix
>> use Date::Format; # requires OpenPKG perl-time
>>
>> my $db_file = $ARGV[0];
>>
>> my $db = DBIx::Simple->connect(
>> "dbi:SQLite:dbname=$db_file", "", "",
>> { RaiseError => 0, AutoCommit => 0 }
>> );
>>
>> my $eow = q{\x00\s.,:;?!)"'};
>>
>> sub fixup {
>> my ($data) = @_;
>> if ($$data =~ m:/[^$eow]*/[^$eow]*'[^$eow]+:s) {
>> $$data =~ s:(/[^$eow]*/[^$eow]*)('[^$eow]+):$1 $2:sg;
>> return 1;
>> }
>> return 0;
>> }
>>
>> foreach my $rec ($db->query("SELECT name, invtime, text FROM
>wiki")->hashes()) {
>> if (&fixup(\$rec->{"text"})) {
>> printf("++ adjusting Wiki page \"%s\" as of %s\n",
>> $rec->{"name"}, time2str("%Y-%m-%d %H:%M:%S", -$rec-
>>{"invtime"}));
>> $db->query("UPDATE wiki SET text = ? WHERE name = ? AND
>invtime = ?",
>> $rec->{"text"}, $rec->{"name"}, $rec->{"invtime"});
>> }
>> }
>> foreach my $rec ($db->query("SELECT tn, description, remarks
>FROM ticket")->hashes()) {
>> if (&fixup(\$rec->{"description"}) or &fixup(\$rec-
>>{"remarks"})) {
>> printf("++ adjusting ticket #%d\n",
>> $rec->{"tn"});
>> $db->query("UPDATE ticket SET description = ?, remarks =
>? WHERE tn = ?",
>> $rec->{"description"}, $rec->{"remarks"}, $rec-
>>{"tn"});
>> }
>> }
>> foreach my $rec ($db->query("SELECT tn, chngtime, oldval, newval
>FROM tktchng")->hashes()) {
>> if (&fixup(\$rec->{"oldval"}) or &fixup(\$rec->{"newval"}))
>{
>> printf("++ adjusting ticket [%d] change as of %s\n",
>> $rec->{"tn"}, time2str("%Y-%m-%d %H:%M:%S", $rec-
>>{"chngtime"}));
>> $db->query("UPDATE tktchng SET oldval = ?, newval = ?
>WHERE tn = ? AND chngtime = ?",
>> $rec->{"oldval"}, $rec->{"newval"}, $rec->{"tn"},
>$rec->{"chngtime"});
>> }
>> }
>> foreach my $rec ($db->query("SELECT cn, message FROM chng")-
>>hashes()) {
>> if (&fixup(\$rec->{"message"})) {
>> printf("++ adjusting change [%d]\n",
>> $rec->{"cn"});
>> $db->query("UPDATE chng SET message = ? WHERE cn = ?",
>> $rec->{"message"}, $rec->{"cn"});
>> }
>> }
>>
>> $db->commit();
>> $db->disconnect();
>>
>> RESOLUTION
>> ----------
>>
>> Upgrade to the now available CVSTrac 2.0.1:
>> http://www.cvstrac.org/cvstrac-2.0.1.tar.gz
>>
>> Or apply the following upstream vendor patch against CVSTrac
>2.0.0:
>> http://www.cvstrac.org/cvstrac/chngview?cn=852
>>
>> Index: cvstrac/format.c
>> --- format.c 2006/07/05 01:06:50 1.87
>> +++ format.c 2006/08/16 23:02:14 1.88
>> @@ -77,6 +77,8 @@
>> ** Return TRUE if *z points to the terminator for a word.
>Words
>> ** are terminated by whitespace or end of input or any of the
>> ** characters in zEnd.
>> +** Note that is_eow() ignores zEnd characters _inside_ a word.
>They
>> +** only count if they're followed by other EOW characters.
>> */
>> int is_eow(const char *z, const char *zEnd){
>> if( zEnd==0 ) zEnd = ".,:;?!)\"'";
>> @@ -123,6 +125,7 @@
>> ** somewhere inside. Spaces in filenames aren't supported.
>> */
>> int is_repository_file(const char *z){
>> + char *s;
>> int i;
>> int gotslash=0;
>> if( z[0]!='/' ) return 0;
>> @@ -132,13 +135,12 @@
>> if(!gotslash) return 0;
>>
>> /* see if it's in the repository. Note that we strip the
>leading '/' from the
>> - * query. Note that the is_eow() check means there's no '
>character.
>> + * query.
>> */
>> - if( !db_exists("SELECT filename FROM filechng WHERE
>filename='%.*s'",
>> - i-1, &z[1]) ){
>> - return 0;
>> - }
>> - return i;
>> + s = mprintf("%.*s", i-1, &z[1]);
>> + gotslash = db_exists("SELECT filename FROM filechng WHERE
>filename='%q'", s );
>> + free(s);
>> + return gotslash ? i : 0;
>> }
>>
>> /*
>>
>> HISTORY
>> -------
>>
>> 2007-01-17 10:00 UTC: problem detected
>> 2007-01-17 11:30 UTC: vulnerability detected in
>format.c:is_eow()
>> 2007-01-17 12:15 UTC: vulnerability analized and first
>workaround patch created
>> 2007-01-17 12:45 UTC: database resurrection script written
>> 2007-01-17 13:00 UTC: upstream vendor notified
>> 2007-01-17 22:24 UTC: vendor confirmed vulnerability and
>provided official fix
>> 2007-01-18 09:22 UTC: vendor informed and CVE number requested
>from MITRE
>> 2007-01-18 20:08 UTC: received CVE number CVE-2007-0347 from
>MITRE
>> 2007-01-22 08:30 UTC: settled with vendor on an embargo date of
>2007-01-29 12:00 UTC
>> 2007-01-22 09:00 UTC: pre-informed "vendor-sec"
>> 2007-01-29 12:00 UTC: send out RSE security advisory
>>
>> Ralf S. Engelschall
>> rse@...elschall.com
>> www.engelschall.com
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 29 Jan 2007 14:03:14 +0100
>> From: OpenPKG GmbH <openpkg-noreply@...npkg.com>
>> Subject: [Full-disclosure] [OpenPKG-SA-2007.008] OpenPKG
>Security
>> Advisory (cvstrac)
>> To: full-disclosure@...ts.grok.org.uk
>> Message-ID: <OpenPKG-SA-2007.008@...npkg.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>___________________________________________________________________
>_________
>>
>> Publisher Name: OpenPKG GmbH
>> Publisher Home: http://openpkg.com/
>>
>> Advisory Id (public): OpenPKG-SA-2007.008
>> Advisory Type: OpenPKG Security Advisory (SA)
>> Advisory Directory: http://openpkg.com/go/OpenPKG-SA
>> Advisory Document: http://openpkg.com/go/OpenPKG-SA-
>2007.008
>> Advisory Published: 2007-01-29 14:02 UTC
>>
>> Issue Id (internal): OpenPKG-SI-20070117.01
>> Issue First Created: 2007-01-17
>> Issue Last Modified: 2007-01-29
>> Issue Revision: 08
>>
>___________________________________________________________________
>_________
>>
>> Subject Name: cvstrac
>> Subject Summary: VCS web frontend
>> Subject Home: http://www.cvstrac.org/
>> Subject Versions: * = 2.0.0
>>
>> Vulnerability Id: CVE-2007-0347
>> Vulnerability Scope: global (not OpenPKG specific)
>>
>> Attack Feasibility: run-time
>> Attack Vector: remote network
>> Attack Impact: denial of service
>>
>> Description:
>> Ralf S. Engelschall from OpenPKG GmbH discovered a Denial of
>Service
>> (DoS) vulnerability in the CVS/Subversion/Git Version
>Control System
>> (VCS) frontend CVSTrac [0], version 2.0.0.
>>
>> The vulnerability is in the Wiki-style text output formatter
>and is
>> triggered by special text constructs in commit messages,
>tickets and
>> Wiki pages. Only users with check-in permissions and Wiki or
>ticket
>> edit permissions can perform an attack. But as the anonymous
>user
>> usually is granted Wiki edit and ticket creation
>permissions, an
>> attacker remotely and anonymously can cause a partial DoS
>(depending
>> on the pages requested) on a CVSTrac installation by opening
>a new
>> ticket or editing a Wiki page with an arbitrary text
>containing for
>> instance the string "/foo/bar'quux".
>>
>> The DoS vulnerability exists because the is_eow() function
>in
>> "format.c" does NOT just check the FIRST character of the
>supplied
>> string for an End-Of-Word terminating character, but instead
>> iterates over string and this way can skip a single embedded
>> quotation mark. The is_repository_file() function then in
>turn
>> assumes that the filename string can never contain a single
>> quotation mark and traps into an SQL escaping problem.
>>
>> An SQL injection via this technique is somewhat limited as
>is_eow()
>> bails on whitespace. So while one _can_ do an SQL injection,
>one is
>> limited to SQL queries containing only characters which get
>past the
>> function isspace(3). This effectively limits attacks to SQL
>commands
>> like "VACUUM".
>>
>> Administrators can quickly workaround by revoking
>permissions on the
>> users. Restoring those permissions, obviously, would require
>keeping
>> vulnerable permissions on at least one infrequently used
>account
>> like "setup" or using the CLI sqlite3(1) to manually add
>them back
>> later.
>>
>> References:
>> [0] http://www.cvstrac.org/
>>
>___________________________________________________________________
>_________
>>
>> Primary Package Name: cvstrac
>> Primary Package Home: http://openpkg.org/go/package/cvstrac
>>
>> Corrected Distribution: Corrected Branch: Corrected Package:
>> OpenPKG Enterprise E1.0-SOLID cvstrac-2.0.0-E1.0.2
>>
>___________________________________________________________________
>_________
>>
>> For security reasons, this document was digitally signed with
>the
>> OpenPGP public key of the OpenPKG GmbH (public key id 61B7AE34)
>> which you can download from http://openpkg.com/openpkg.com.pgp
>> or retrieve from the OpenPGP keyserver at
>hkp://pgp.openpkg.org/.
>> Follow the instructions at
>http://openpkg.com/security/signatures/
>> for more details on how to verify the integrity of this
>document.
>>
>___________________________________________________________________
>_________
>>
>> -----BEGIN PGP SIGNATURE-----
>> Comment: OpenPKG GmbH <http://openpkg.com/>
>>
>> iD8DBQFFvfCEZwQuyWG3rjQRApMLAJ0Q/mkpIIar3VjFoMVay7b70i5DIwCfX8lJ
>> 6ITu0bSW6c3RR9sQ6q6cIpQ=
>> =kxz6
>> -----END PGP SIGNATURE-----
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 29 Jan 2007 17:00:00 -0000
>> From: "David Litchfield" <davidl@...software.com>
>> Subject: [Full-disclosure] Oracle - Indirect Privilege
>Escalation and
>> Defeating Virtual Private Databases
>> To: <bugtraq@...urityfocus.com>
>> Cc: full-disclosure@...ts.grok.org.uk, dbsec@...elists.org
>> Message-ID: <001901c743c6$ecf65260$4601a8c0@...software.com>
>> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>> reply-type=original
>>
>> Hey all,
>> For anyone that's interested I've just put out two papers
>(chapters really);
>> one on Indirect Privilege Escalation in Oracle and the other on
>Defeating
>> Virtual Private Databases in Oracle. You can grab them here.
>> http://www.databasesecurity.com/dbsec/ohh-indirect-privilege-
>escalation.pdf
>> http://www.databasesecurity.com/dbsec/ohh-defeating-vpd.pdf
>> Cheers,
>> David
>>
>> --
>> E-MAIL DISCLAIMER
>>
>> The information contained in this email and any subsequent
>> correspondence is private, is solely for the intended
>recipient(s) and
>> may contain confidential or privileged information. For those
>other than
>> the intended recipient(s), any disclosure, copying,
>distribution, or any
>> other action taken, or omitted to be taken, in reliance on such
>> information is prohibited and may be unlawful. If you are not
>the
>> intended recipient and have received this message in error,
>please
>> inform the sender and delete this mail and any attachments.
>>
>> The views expressed in this email do not necessarily reflect NGS
>policy.
>> NGS accepts no liability or responsibility for any onward
>transmission
>> or use of emails and attachments having left the NGS domain.
>>
>> NGS and NGSSoftware are trading names of Next Generation
>Security
>> Software Ltd. Registered office address: 52 Throwley Way,
>Sutton, SM1
>> 4BF with Company Number 04225835 and VAT Number 783096402
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 30 Jan 2007 08:25:27 +1030
>> From: S?nnet Beskerming <info@...kerming.com>
>> Subject: [Full-disclosure] Phishing Evolution Report Released
>> To: full-disclosure@...ts.grok.org.uk
>> Message-ID: <2DD1B718-CA53-4A3D-87C7-
>4B6A2BF5487B@...kerming.com>
>> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes;
>format=flowed
>>
>> Hello List(s),
>>
>> For those interested in the original FD email about a new
>phishing
>> technique being employed on a professional networking site (late
>last
>> week), the investigation and subsequent report have been
>published.
>> Readers of 'The Register' will note a write up already in place
>with
>> some feedback from the site involved. Although the claim of 10
>or so
>> reports per month of similar scams being made are probable, I
>doubt
>> that many (if any) have taken as much detailed involvement from
>the
>> scammer before the phish is set.
>>
>> http://www.theregister.co.uk/2007/01/29/ecademy_419_scam/
>>
>> You can find the report at the following address:
>>
>> http://www.beskerming.com/marketing/reports/index.html
>>
>> Or, for the direct link:
>>
>> http://www.beskerming.com/marketing/reports/
>> Beskerming_Phishing_Report_Jan_07.pdf
>>
>> A higher detailed version is available upon request, which
>includes
>> sufficient detail in the account screenshots for the profile
>text to
>> be legible.
>>
>> An Executive Summary for those who don't want to read the
>report:
>>
>> - Yes, it was a scam. The scammer started out with a stolen
>> identity, maintaining it all the way through the scam (even when
>
>> confronted)
>> - Ultimately it was a 419-style phish / scam that was traced
>back
>> to Nigeria
>> - The first recorded use of the particular stolen identity was
>
>> November 06, with a very similar scam (though a more traditional
>mass
>> spam email).
>> - The scammer invested at least 2-3 days of communication and
>trust-
>> building before beginning to seed the phish / scam
>> - The initial round of the phish bait was mild enough to
>almost be
>> missed.
>> - The Networking site was VERY prompt in addressing the
>situation
>> once notified (less than 5 minutes to remove the account when it
>
>> reappeared and they were notified again). Props to Ecademy in
>this
>> case.
>> - Sometimes you just need to be paranoid.
>>
>> Any questions or queries, just ask them.
>>
>> Carl
>>
>> S?nnet Beskerming Pty. Ltd.
>> Adelaide, Australia
>> http://www.beskerming.com
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Mon, 29 Jan 2007 11:42:35 +0100
>> From: "Andres Tarasco" <atarasco@...il.com>
>> Subject: [Full-disclosure] Universal printer provider exploit
>for
>> Windows
>> To: full-disclosure@...ts.grok.org.uk
>> Message-ID:
>> <80321d330701290242h56879d87jc346fc5fd3a9386c@...l.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> We have developed a new exploit that should allow code execution
>as SYSTEM
>> with the following software:
>>
>> - DiskAccess NFS Client (dapcnfsd.dll v0.6.4.0) - REPORTED &
>NOTFIXED
>> -0day!!!
>> - Citrix Metaframe - cpprov.dll - FIXED
>> - Novell (nwspool.dll - CVE-2006-5854 - untested. pls give
>feedback)
>> More information at :
>> http://www.514.es/2007/01/universal_exploit_for_vulnerab.html
>(spanish)
>> exploit code:
>>
>http://www.514.es/2007/01/29/Universal_printer_provider_exploit.zip
>
>>
>> /*
>> Title: Universal exploit for vulnerable printer providers
>(spooler service).
>> Vulnerability: Insecure EnumPrintersW() calls
>> Author: Andres Tarasco Acu?a - atarasco@....es
>> Website: http://www.514.es
>>
>>
>> This code should allow to gain SYSTEM privileges with the
>following
>> software:
>> blink !blink! blink!
>>
>> - DiskAccess NFS Client (dapcnfsd.dll v0.6.4.0) - REPORTED &
>NOTFIXED
>> -0day!!!
>> - Citrix Metaframe - cpprov.dll - FIXED
>> - Novell (nwspool.dll - CVE-2006-5854 - untested)
>> - More undisclosed stuff =)
>>
>> If this code crashes your spooler service (spoolsv.exe) check
>your
>> "vulnerable" printer providers at:
>>
>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers
>
>>
>> Workaround: Trust only default printer providers "Internet
>Print Provider"
>>
>> and "LanMan Print Services" and delete the other ones.
>>
>> And remember, if it doesnt work for you, tweak it yourself. Do
>not ask
>>
>>
>> D:\Programaci?n\EnumPrinters\Exploits>testlpc.exe
>> [+] Citrix Presentation Server - EnumPrinterW() Universal
>exploit
>> [+] Exploit coded by Andres Tarasco - atarasco@....es
>>
>>
>> [+] Connecting to spooler LCP port \RPC Control\spoolss
>> [+] Trying to locate valid address (1 tries)
>> [+] Mapped memory. Client address: 0x003d0000
>> [+] Mapped memory. Server address: 0x00a70000
>> [+] Targeting return address to : 0x00A700A7
>> [+] Writting to shared memory...
>> [+] Written 0x1000 bytes
>> [+] Exploiting vulnerability....
>> [+] Exploit complete. Now Connect to 127.0.0.1:51477
>>
>>
>> D:\Programaci?n\EnumPrinters>nc localhost 51477
>> Microsoft Windows XP [Versi?n 5.1.2600]
>> (C) Copyright 1985-2001 Microsoft Corp.
>>
>> C:\WINDOWS\system32>whoami
>> NT AUTHORITY\SYSTEM
>>
>> regards,
>>
>> Andres Tarasco
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.grok.org.uk/pipermail/full-
>disclosure/attachments/20070129/4cb1999a/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Tue, 30 Jan 2007 02:14:53 +0100
>> From: Uwe Hermann <uwe@...mann-uwe.de>
>> Subject: [Full-disclosure] [DRUPAL-SA-2007-005] Drupal 4.7.6 /
>5.1
>> fixes arbitrary code execution issue
>> To: bugtraq@...urityfocus.com, full-
>disclosure@...ts.grok.org.uk,
>> phpsec@...arch.com
>> Message-ID: <20070130011452.GA31240@...enwood>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> -----------------------------------------------------------------
>-----------
>> Drupal security advisory DRUPAL-
>SA-2007-005
>> -----------------------------------------------------------------
>-----------
>> Project: Drupal core
>> Version: 4.7.x, 5.x
>> Date: 2007-Jan-29
>> Security risk: Highy critical
>> Exploitable from: Remote
>> Vulnerability: Arbitrary code execution
>> -----------------------------------------------------------------
>-----------
>>
>> Description
>> -----------
>> Previews on comments were not passed through normal form
>validation routines,
>> enabling users with the 'post comments' permission and access to
>more than
>> one input filter to execute arbitrary code. By default,
>anonymous and
>> authenticated users have access to only one input format.
>>
>> Immediate workarounds include: disabling the comment module,
>revoking the
>> 'post comments' permission for all users or limiting access to
>one input
>> format.
>>
>> Versions affected
>> -----------------
>> - Drupal 4.7.x versions before Drupal 4.7.6
>> - Drupal 5.x versions before Drupal 5.1
>>
>> Solution
>> --------
>> - If you are running Drupal 4.7.x then upgrade to Drupal 4.7.6.
>> http://ftp.osuosl.org/pub/drupal/files/projects/drupal-
>4.7.6.tar.gz
>> - If you are running Drupal 5.x then upgrade to Drupal 5.1.
>> http://ftp.osuosl.org/pub/drupal/files/projects/drupal-
>5.1.tar.gz
>>
>> - To patch Drupal 4.7.5 use
>> http://drupal.org/files/sa-2007-005/SA-2007-005-4.7.5.patch.
>> - To patch Drupal 5.0 use
>> http://drupal.org/files/sa-2007-005/SA-2007-005-5.0.patch.
>>
>> Please note that the patches only contain changes related to
>this advisory,
>> and do not fix bugs that were solved in 4.7.6 or 5.1.
>>
>> Reported by
>> -----------
>> The Drupal security team.
>>
>> Contact
>> -------
>> The security contact for Drupal can be reached at security at
>drupal.org
>> or using the form at http://drupal.org/contact.
>>
>>
>> // Uwe Hermann, on behalf of the Drupal Security Team.
>> --
>> http://www.hermann-uwe.de | http://www.holsham-traders.de
>> http://www.crazy-hacks.org | http://www.unmaintained-free-
>software.org
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: not available
>> Type: application/pgp-signature
>> Size: 189 bytes
>> Desc: Digital signature
>> Url : http://lists.grok.org.uk/pipermail/full-
>disclosure/attachments/20070130/eb3c84da/attachment-0001.bin
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Mon, 29 Jan 2007 21:26:37 -0500
>> From: Jim Popovitch <jimpop@...oo.com>
>> Subject: [Full-disclosure] PC/Laptop microphones
>> To: full-disclosure@...ts.grok.org.uk
>> Message-ID: <1170123997.26901.7.camel@...alhost>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> I started this discussion elsewhere, but I feel that there is
>more
>> experience and concern here. When I look at BIOS settings I
>see config
>> options to disable sound cards, USB, CDROM, INTs, etc., but what
>about
>> the PC or laptop microphone? Does disabling the sound card
>remove the
>> availability of a built-in microphone? What if I want to play
>mp3s but
>> never have the need to use a microphone? Given recent info about
>the US
>> FBIs capabilities to remotely enable mobile phone microphones
>> (presumably via corporate cellular service providers), what
>prevents my
>> OS provider (or distribution) and ISP from working on a way to
>listen in
>> on my office or home conversations via the microphone or the
>built-in
>> speakers? Thoughts?
>>
>> -Jim P.
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: not available
>> Type: application/pgp-signature
>> Size: 189 bytes
>> Desc: This is a digitally signed message part
>> Url : http://lists.grok.org.uk/pipermail/full-
>disclosure/attachments/20070129/f4dd0b81/attachment-0001.bin
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Mon, 29 Jan 2007 21:31:00 -0500
>> From: Clay Seaman-Kossmeyer <ckossmey@...co.com>
>> Subject: Re: [Full-disclosure] S21sec-034-en: Cisco VTP DoS
>> vulnerability
>> To: S21sec Labs <labs@...sec.com>
>> Cc: ckossmey@...co.com, full-disclosure@...ts.grok.org.uk,
>> bugtraq@...urityfocus.com
>> Message-ID: <20070130023100.GH648@...co.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> Hello -
>>
>> Cisco has posted a Security Response in reference to this issue
>at the
>> following URL:
>>
>> http://www.cisco.com/warp/public/707/cisco-sr-20070129-vtp.shtml
>>
>> Cisco Response
>> ==============
>>
>> An issue has been reported to the Cisco PSIRT involving
>malformed VLAN
>> Trunking Protocol (VTP) packets. This attack may cause the
>target
>> device to reload, causing a Denial of Service (DoS).
>>
>> Such an attack must be executed on a local ethernet segment, and
>the
>> VTP domain name must be known to the attacker. Additionally,
>these
>> attacks must be executed against a switch port that is
>configured for
>> trunking. Non-trunk access ports are not affected.
>>
>> This issue is tracked as Cisco Bug ID CSCsa67294.
>>
>> Details
>> =======
>>
>> The VLAN Trunking Protocol (VTP) is a Layer 2 protocol that
>manages
>> the addition, deletion, and renaming of VLANS on a network-wide
>basis
>> in order to maintain VLAN configuration consistency.
>>
>> VTP packets are exchanged by VLAN-aware switches. For more
>information
>> on VTP, consult the following link:
>>
>>
>http://www.cisco.com/en/US/products/hw/switches/ps663/products_conf
>iguration_guide_chapter09186a00800e47e3.html.
>>
>> Upon receiving a malformed VTP packet, certain devices may
>reload. The
>> attack could be executed repeatedly causing a extended Denial of
>> Service.
>>
>> In order to successfully exploit this vulnerability, the
>attacker must
>> know the VTP domain name, as well as send the malformed VTP
>packet to
>> a port on the switch configured for trunking.
>>
>> This does not affect switch ports that are configured for voice
>> vlans. A complete Inter-Switch Link (ISL) or 802.1q trunk port
>is
>> required for the device to be vulnerable.
>>
>> These platforms are affected:
>>
>> * Cisco 2900XL Series Switches
>> * Cisco 2950 Series Switches
>> * Cisco 2955 Series Switches
>> * Cisco 3500XL Series Switches
>> * Cisco 3550 Series Switches
>> * Cisco 3570 Series Switches
>>
>> No other Cisco products are known to be vulnerable to this
>issue.
>>
>> This issue was made public on 26-Jan-2007 on the Full-Disclosure
>and
>> Bugtraq mailing lists. The Cisco bug ID CSCsa67294 was made
>available
>> to registered customers in May of 2005.
>>
>> We would like to thank David Barroso Berrueta and Alfredo Andres
>> Omella for reporting this vulnerability to us. You can find
>their
>> release here: http://www.s21sec.com/es/avisos/s21sec-034-en.txt.
>>
>> We greatly appreciate the opportunity to work with researchers
>on
>> security vulnerabilities and welcome the opportunity to review
>and
>> assist in security vulnerability reports against Cisco products.
>>
>> Workarounds
>> ===========
>>
>> In order to mitigate your exposure, ensure that only known,
>trusted
>> devices are connected to ports configured for ISL or 802.1q
>trunking.
>>
>> More information on securing L2 networks can be found in the
>Cisco
>> SAFE Layer 2 Security document at this location:
>>
>>
>http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networkin
>g_solutions_white_paper09186a008014870f.shtml
>>
>> Additional Information
>> ======================
>>
>> THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY
>ANY
>> KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
>> MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
>> INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE
>DOCUMENT IS
>> AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE
>THIS
>> DOCUMENT AT ANY TIME.
>>
>> Revision History
>> ================
>>
>> +--------------+------------------+------------------------+
>> | Revision 1.0 | 2007-January-29 | Initial public release |
>> +--------------+------------------+------------------------+
>>
>> Cisco Security Procedures
>> =========================
>>
>> Complete information on reporting security vulnerabilities in
>Cisco
>> products, obtaining assistance with security incidents, and
>> registering to receive security information from Cisco, is
>available
>> on Cisco's worldwide website at
>>
>http://www.cisco.com/en/US/products/products_security_vulnerability
>_policy.html.
>> This includes instructions for press inquiries regarding Cisco
>> security notices. All Cisco security advisories are available at
>> http://www.cisco.com/go/psirt.
>>
>>
>>
>> On Fri, Jan 26, 2007 at 02:46:43PM -0500, S21sec Labs wrote:
>> >
>###############################################################
>> > ID: S21SEC-034-en
>> > Title: Cisco VTP Denial Of Service
>> > Date: 26/01/2007
>> > Status: Vendor contacted, bug fixed
>> > Severity: Medium - DoS - remote from the local subnet
>> > Scope: Cisco Catalyst Switch denial of service
>> > Platforms: IOS
>> > Author: Alfredo Andres Omella, David Barroso Berrueta
>> > Location: http://www.s21sec.com/es/avisos/s21sec-034-en.txt
>> > Release: Public
>> >
>###############################################################
>> >
>> > S 2 1 S E C
>> >
>> > http://www.s21sec.com
>> >
>> > Cisco VTP Denial Of Service
>> >
>> >
>> > About VTP
>> > ---------
>> >
>> > VTP (VLAN Trunking Protocol) is a Cisco proprietary protocol
>used for
>> > VLAN centralized management.
>> > For instance, when you configure a VLAN in a switch, the VLAN
>
>> > information (the VLAN name and its identifier)
>> > will be configured automatically in all the switches that
>belong to
>> > the same VTP domain.
>> >
>> >
>> > Description of vulnerability
>> > ----------------------------
>> >
>> > VTP uses Subset-Advert messages to advertise the existing
>VLANs
>> > within a VTP domain,
>> > sending a malformed crafted packet it is possible to force a
>switch
>> > "crash & reload". In order to trigger the vulnerability,
>> > you need to previously set up the trunking (manually or using
>
>> > Yersinia DTP attack).
>> >
>> >
>> > Affected Versions and platforms
>> > -------------------------------
>> >
>> > This vulnerability has been tested against Cisco Catalyst
>2950T
>> > switches with IOS 12.1(22)EA3.
>> > Other versions are probably vulnerable.
>> >
>> >
>> > Solution
>> > --------
>> >
>> > According to Cisco PSIRT, it is already fixed. We don't know
>all the
>> > details because
>> > Cisco tagged (back in 2005) the issue as an "internal bug",
>not as a
>> > security vulnerability.
>> > Upgrade your IOS to the latest release.
>> >
>> >
>> > Additional information
>> > ----------------------
>> >
>> > This vulnerability has been found and researched by:
>> >
>> > David Barroso Berrueta dbarroso@...sec.com
>> > Alfredo Andres Omella aandres@...sec.com
>> >
>> > It was found on January 2005 and shown in a real demo at
>BlackHat
>> > Europe Briefings 2005 (March 2005) (Yersinia, a framework for
>layer 2
>> > attacks).
>> > Some months later, FX from Phenoelit found other VTP
>vulnerabilities:
>> > http://www.securityfocus.com/archive/1/445896/30/0/threaded
>> > Cisco released then an answer to FX
>(http://www.cisco.com/warp/public/
>> > 707/cisco-sr-20060913-vtp.shtml) but as there is no any
>comment about
>> > this
>> > specific vulnerability we suppose that it is not related with
>this one.
>> >
>> > This vulnerability has been implemented in the current
>Yersinia
>> > version, under the VTP attacks (see the src/vtp.c file) .
>> > Yersinia homepage: http://www.yersinia.net
>> >
>> > You can find this advisory at:
>> > http://www.s21sec.com/en/avisos/s21sec-034-en.txt
>> >
>> > Other S21SEC advisories availabe at
>http://www.s21sec.com/en/avisos/
>> >
>> > _______________________________________________
>> > Full-Disclosure - We believe in it.
>> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> > Hosted and sponsored by Secunia - http://secunia.com/
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.5 (Darwin)
>>
>> iD8DBQFFvq3REHa/Ybuq8nARAlZ9AJ4zzh8a7qwluYP94oAf/WFMfmzrZwCgpiDl
>> JxK2NENYveWy7rIf/SL/dBo=
>> =IaMi
>> -----END PGP SIGNATURE-----
>>
>>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Tue, 30 Jan 2007 03:52:51 +0100
>> From: "Tyop?" <tyoptyop@...il.com>
>> Subject: Re: [Full-disclosure] PC/Laptop microphones
>> To: "Jim Popovitch" <jimpop@...oo.com>,
>> full-disclosure@...ts.grok.org.uk
>> Message-ID:
>> <985b1a3d0701291852o369898e6nf2fa1c34b4af86fb@...l.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 1/30/07, Jim Popovitch <jimpop@...oo.com> wrote:
>> > Given recent info about the US
>> > FBIs capabilities to remotely enable mobile phone microphones
>> > (presumably via corporate cellular service providers),
>>
>> Do you have some links on that?
>> Paranoia inside :p
>>
>> --
>> Tyop?
>> Etudiant.
>> http://altmylife.blogspot.com
>>
>>
>>
>> ------------------------------
>>
>> Message: 10
>> Date: Mon, 29 Jan 2007 22:02:14 -0500
>> From: Simon Smith <simon@...soft.com>
>> Subject: Re: [Full-disclosure] PC/Laptop microphones
>> To: Jim Popovitch <jimpop@...oo.com>, Untitled
>> <full-disclosure@...ts.grok.org.uk>
>> Message-ID: <C1E41F66.17BF5%simon@...soft.com>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>> Jim,
>> In all reality you don't have to be an agent to do this.
>You could just
>> write an exploit that when successfully executed would
>compromise the target
>> and then fetch an application from a remote site. I'm sure that
>things like
>> this have been done in the past. Hell imagine what you could do
>with a web
>> cam! ;]
>>
>> New telephones are no different I'm sure.
>>
>> On 1/29/07 9:26 PM, "Jim Popovitch" <jimpop@...oo.com> wrote:
>>
>> > I started this discussion elsewhere, but I feel that there is
>more
>> > experience and concern here. When I look at BIOS settings I
>see config
>> > options to disable sound cards, USB, CDROM, INTs, etc., but
>what about
>> > the PC or laptop microphone? Does disabling the sound card
>remove the
>> > availability of a built-in microphone? What if I want to play
>mp3s but
>> > never have the need to use a microphone? Given recent info
>about the US
>> > FBIs capabilities to remotely enable mobile phone microphones
>> > (presumably via corporate cellular service providers), what
>prevents my
>> > OS provider (or distribution) and ISP from working on a way to
>listen in
>> > on my office or home conversations via the microphone or the
>built-in
>> > speakers? Thoughts?
>> >
>> > -Jim P.
>> > _______________________________________________
>> > Full-Disclosure - We believe in it.
>> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> > Hosted and sponsored by Secunia - http://secunia.com/
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 11
>> Date: Mon, 29 Jan 2007 22:34:18 -0500
>> From: "Clement Dupuis" <cdupuis@...ure.org>
>> Subject: Re: [Full-disclosure] PC/Laptop microphones
>> To: "'Simon Smith'" <simon@...soft.com>, "'Jim Popovitch'"
>> <jimpop@...oo.com>, "'Untitled'" <full-
>disclosure@...ts.grok.org.uk>
>> Message-ID: <00d301c7441f$894d2dc0$c1b211ac@...slaptop>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> This was discussed in the past. It is one of the features
>within Core
>> Impact from Core Security. Here is an old post on the subject:
>>
>> > CORE IMPACT has a Python module (uses win32api)to do just
>that, it is
>> called
>> > "Record audio file" (there is also a "play audio file" and a
>"grab 1 frame
>> > from Webcam")
>> >
>> > Basically, it uses the Windows MCI interface:
>> >
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-
>us/multimed/ht
>> m/_win32_about_mci.asp
>> >
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-
>us/multimed/ht
>> m/_win32_mci_reference.asp
>> >
>> > There is also a generic "Execute MCI string" that we commonly
>use to amuse
>> > ourselves by opening/closing the CD door remotely once we've
>gain access
>> to
>> > a target system running windows.
>> >
>> > It should not be difficult to write your own quickly with
>Python and the
>> > above reference from the MSDN
>> >
>>
>> -----Original Message-----
>> From: Simon Smith [mailto:simon@...soft.com]
>> Sent: Monday, January 29, 2007 10:02 PM
>> To: Jim Popovitch; Untitled
>> Subject: Re: [Full-disclosure] PC/Laptop microphones
>>
>> Jim,
>> In all reality you don't have to be an agent to do this.
>You could just
>> write an exploit that when successfully executed would
>compromise the target
>> and then fetch an application from a remote site. I'm sure that
>things like
>> this have been done in the past. Hell imagine what you could do
>with a web
>> cam! ;]
>>
>> New telephones are no different I'm sure.
>>
>> On 1/29/07 9:26 PM, "Jim Popovitch" <jimpop@...oo.com> wrote:
>>
>> > I started this discussion elsewhere, but I feel that there is
>more
>> > experience and concern here. When I look at BIOS settings I
>see config
>> > options to disable sound cards, USB, CDROM, INTs, etc., but
>what about
>> > the PC or laptop microphone? Does disabling the sound card
>remove the
>> > availability of a built-in microphone? What if I want to play
>mp3s but
>> > never have the need to use a microphone? Given recent info
>about the US
>> > FBIs capabilities to remotely enable mobile phone microphones
>> > (presumably via corporate cellular service providers), what
>prevents my
>> > OS provider (or distribution) and ISP from working on a way to
>listen in
>> > on my office or home conversations via the microphone or the
>built-in
>> > speakers? Thoughts?
>> >
>> > -Jim P.
>> > _______________________________________________
>> > 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/
>>
>>
>>
>> ------------------------------
>>
>> Message: 12
>> Date: Mon, 29 Jan 2007 23:13:01 -0500
>> From: Jim Popovitch <jimpop@...oo.com>
>> Subject: Re: [Full-disclosure] PC/Laptop microphones
>> To: full-disclosure <full-disclosure@...ts.grok.org.uk>
>> Message-ID: <1170130381.3177.1.camel@...alhost>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> On Tue, 2007-01-30 at 03:52 +0100, Tyop? wrote:
>> > On 1/30/07, Jim Popovitch <jimpop@...oo.com> wrote:
>> > > Given recent info about the US
>> > > FBIs capabilities to remotely enable mobile phone
>microphones
>> > > (presumably via corporate cellular service providers),
>> >
>> > Do you have some links on that?
>> > Paranoia inside :p
>>
>> ;-) Paranoia is a good characteristic to have.
>>
>> Here's a few references:
>> http://www.google.com/search?hl=en&q=FBI+Mob+microphone
>>
>>
>>
>> -Jim P.
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: not available
>> Type: application/pgp-signature
>> Size: 189 bytes
>> Desc: This is a digitally signed message part
>> Url : http://lists.grok.org.uk/pipermail/full-
>disclosure/attachments/20070129/3ecbecb4/attachment-0001.bin
>>
>> ------------------------------
>>
>> Message: 13
>> Date: Mon, 29 Jan 2007 23:29:26 -0500
>> From: Simon Smith <simon@...soft.com>
>> Subject: Re: [Full-disclosure] PC/Laptop microphones
>> To: Jim Popovitch <jimpop@...oo.com>, Untitled
>> <full-disclosure@...ts.grok.org.uk>
>> Message-ID: <C1E433D6.17BFA%simon@...soft.com>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>> Who's paranoid, I'm not paranoid, stop talking about me!
>>
>>
>> On 1/29/07 11:13 PM, "Jim Popovitch" <jimpop@...oo.com> wrote:
>>
>> > On Tue, 2007-01-30 at 03:52 +0100, Tyop? wrote:
>> >> On 1/30/07, Jim Popovitch <jimpop@...oo.com> wrote:
>> >>> Given recent info about the US
>> >>> FBIs capabilities to remotely enable mobile phone
>microphones
>> >>> (presumably via corporate cellular service providers),
>> >>
>> >> Do you have some links on that?
>> >> Paranoia inside :p
>> >
>> > ;-) Paranoia is a good characteristic to have.
>> >
>> > Here's a few references:
>> > http://www.google.com/search?hl=en&q=FBI+Mob+microphone
>> >
>> >
>> >
>> > -Jim P.
>> > _______________________________________________
>> > Full-Disclosure - We believe in it.
>> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> > Hosted and sponsored by Secunia - http://secunia.com/
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 14
>> Date: Tue, 30 Jan 2007 01:03:48 -0500
>> From: Clay Seaman-Kossmeyer <ckossmey@...co.com>
>> Subject: Re: [Full-disclosure] S21sec-034-en: Cisco VTP DoS
>> vulnerability
>> To: S21sec Labs <labs@...sec.com>
>> Cc: full-disclosure@...ts.grok.org.uk,
>bugtraq@...urityfocus.com,
>> psirt@...co.com
>> Message-ID: <20070130060348.GC823@...co.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> Hello -
>>
>> Cisco's response follows for this issue:
>>
>> Cisco Response
>> ==============
>>
>> An issue has been reported to the Cisco PSIRT involving
>malformed VLAN
>> Trunking Protocol (VTP) packets. This attack may cause the
>target
>> device to reload, causing a Denial of Service (DoS).
>>
>> Such an attack must be executed on a local ethernet segment, and
>the
>> VTP domain name must be known to the attacker. Additionally,
>these
>> attacks must be executed against a switch port that is
>configured for
>> trunking. Non-trunk access ports are not affected.
>>
>> This issue is tracked as Cisco Bug ID CSCsa67294.
>>
>> Details
>> =======
>>
>> The VLAN Trunking Protocol (VTP) is a Layer 2 protocol that
>manages
>> the addition, deletion, and renaming of VLANS on a network-wide
>basis
>> in order to maintain VLAN configuration consistency.
>>
>> VTP packets are exchanged by VLAN-aware switches. For more
>information
>> on VTP, consult the following link:
>>
>>
>http://www.cisco.com/en/US/products/hw/switches/ps663/products_conf
>iguration_guide_chapter09186a00800e47e3.html.
>>
>> Upon receiving a malformed VTP packet, certain devices may
>reload. The
>> attack could be executed repeatedly causing a extended Denial of
>> Service.
>>
>> In order to successfully exploit this vulnerability, the
>attacker must
>> know the VTP domain name, as well as send the malformed VTP
>packet to
>> a port on the switch configured for trunking.
>>
>> This does not affect switch ports that are configured for voice
>> vlans. A complete Inter-Switch Link (ISL) or 802.1q trunk port
>is
>> required for the device to be vulnerable.
>>
>> These platforms are affected:
>>
>> * Cisco 2900XL Series Switches
>> * Cisco 2950 Series Switches
>> * Cisco 2955 Series Switches
>> * Cisco 3500XL Series Switches
>> * Cisco 3550 Series Switches
>> * Cisco 3570 Series Switches
>>
>> No other Cisco products are known to be vulnerable to this
>issue.
>>
>> This issue was made public on 26-Jan-2007 on the Full-Disclosure
>and
>> Bugtraq mailing lists. The Cisco bug ID CSCsa67294 was made
>available
>> to registered customers in May of 2005.
>>
>> We would like to thank David Barroso Berrueta and Alfredo Andres
>> Omella for reporting this vulnerability to us. You can find
>their
>> release here: http://www.s21sec.com/es/avisos/s21sec-034-en.txt.
>>
>> We greatly appreciate the opportunity to work with researchers
>on
>> security vulnerabilities and welcome the opportunity to review
>and
>> assist in security vulnerability reports against Cisco products.
>>
>> Workarounds
>> ===========
>>
>> In order to mitigate your exposure, ensure that only known,
>trusted
>> devices are connected to ports configured for ISL or 802.1q
>trunking.
>>
>> More information on securing L2 networks can be found in the
>Cisco
>> SAFE Layer 2 Security document at this location:
>>
>http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networkin
>g_solutions_white_paper09186a008014870f.shtml
>>
>> Additional Information
>> ======================
>>
>> THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY
>ANY
>> KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
>> MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
>> INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE
>DOCUMENT IS
>> AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE
>THIS
>> DOCUMENT AT ANY TIME.
>>
>> Revision History
>> ================
>>
>> +--------------+-----------------+------------------------+
>> | Revision 1.0 | 2007-January-29 | Initial public release |
>> +--------------+-----------------+------------------------+
>>
>> Cisco Security Procedures
>> =========================
>>
>> Complete information on reporting security vulnerabilities in
>Cisco
>> products, obtaining assistance with security incidents, and
>> registering to receive security information from Cisco, is
>available
>> on Cisco's worldwide website at
>>
>http://www.cisco.com/en/US/products/products_security_vulnerability
>_policy.html.
>> This includes instructions for press inquiries regarding Cisco
>> security notices. All Cisco security advisories are available at
>> http://www.cisco.com/go/psirt.
>>
>>
>> On Fri, Jan 26, 2007 at 02:46:43PM -0500, S21sec Labs wrote:
>> >
>###############################################################
>> > ID: S21SEC-034-en
>> > Title: Cisco VTP Denial Of Service
>> > Date: 26/01/2007
>> > Status: Vendor contacted, bug fixed
>> > Severity: Medium - DoS - remote from the local subnet
>> > Scope: Cisco Catalyst Switch denial of service
>> > Platforms: IOS
>> > Author: Alfredo Andres Omella, David Barroso Berrueta
>> > Location: http://www.s21sec.com/es/avisos/s21sec-034-en.txt
>> > Release: Public
>> >
>###############################################################
>> >
>> > S 2 1 S E C
>> >
>> > http://www.s21sec.com
>> >
>> > Cisco VTP Denial Of Service
>> >
>> >
>> > About VTP
>> > ---------
>> >
>> > VTP (VLAN Trunking Protocol) is a Cisco proprietary protocol
>used for
>> > VLAN centralized management.
>> > For instance, when you configure a VLAN in a switch, the VLAN
>
>> > information (the VLAN name and its identifier)
>> > will be configured automatically in all the switches that
>belong to
>> > the same VTP domain.
>> >
>> >
>> > Description of vulnerability
>> > ----------------------------
>> >
>> > VTP uses Subset-Advert messages to advertise the existing
>VLANs
>> > within a VTP domain,
>> > sending a malformed crafted packet it is possible to force a
>switch
>> > "crash & reload". In order to trigger the vulnerability,
>> > you need to previously set up the trunking (manually or using
>
>> > Yersinia DTP attack).
>> >
>> >
>> > Affected Versions and platforms
>> > -------------------------------
>> >
>> > This vulnerability has been tested against Cisco Catalyst
>2950T
>> > switches with IOS 12.1(22)EA3.
>> > Other versions are probably vulnerable.
>> >
>> >
>> > Solution
>> > --------
>> >
>> > According to Cisco PSIRT, it is already fixed. We don't know
>all the
>> > details because
>> > Cisco tagged (back in 2005) the issue as an "internal bug",
>not as a
>> > security vulnerability.
>> > Upgrade your IOS to the latest release.
>> >
>> >
>> > Additional information
>> > ----------------------
>> >
>> > This vulnerability has been found and researched by:
>> >
>> > David Barroso Berrueta dbarroso@...sec.com
>> > Alfredo Andres Omella aandres@...sec.com
>> >
>> > It was found on January 2005 and shown in a real demo at
>BlackHat
>> > Europe Briefings 2005 (March 2005) (Yersinia, a framework for
>layer 2
>> > attacks).
>> > Some months later, FX from Phenoelit found other VTP
>vulnerabilities:
>> > http://www.securityfocus.com/archive/1/445896/30/0/threaded
>> > Cisco released then an answer to FX
>(http://www.cisco.com/warp/public/
>> > 707/cisco-sr-20060913-vtp.shtml) but as there is no any
>comment about
>> > this
>> > specific vulnerability we suppose that it is not related with
>this one.
>> >
>> > This vulnerability has been implemented in the current
>Yersinia
>> > version, under the VTP attacks (see the src/vtp.c file) .
>> > Yersinia homepage: http://www.yersinia.net
>> >
>> > You can find this advisory at:
>> > http://www.s21sec.com/en/avisos/s21sec-034-en.txt
>> >
>> > Other S21SEC advisories availabe at
>http://www.s21sec.com/en/avisos/
>> >
>> > _______________________________________________
>> > Full-Disclosure - We believe in it.
>> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> > Hosted and sponsored by Secunia - http://secunia.com/
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.5 (Darwin)
>>
>> iD8DBQFFvt+IEHa/Ybuq8nARAmapAKCDVkXuNcSL/E5wSf2FBh298vmcOgCfTbKm
>> oaFNJ9jqXSbTzrp5foSQLa8=
>> =q2ut
>> -----END PGP SIGNATURE-----
>>
>>
>>
>> ------------------------------
>>
>> Message: 15
>> Date: Tue, 30 Jan 2007 15:56:59 +0800
>> From: "COSEINC" <alu@...einc.com>
>> Subject: [Full-disclosure] COSEINC Alert: Microsoft Agent Heap
>> Overflow Vulnerability Technical Details (Patched)
>> To: <full-disclosure@...ts.grok.org.uk>
>> Message-ID: <044f01c74444$388c9270$d201000a@...7591890519>
>> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>> reply-type=original
>>
>> Microsoft Agent Heap Overflow Vulnerability
>>
>> COSEINC Alert
>> http://www.coseinc.com/alert.html
>>
>> Vendor:
>> Microsoft
>>
>> Systems Affected:
>> Windows 2000 All Service Packs
>> Windows XP All Service Packs
>>
>> Overview:
>> Microsoft Agent is a software technology that enables an
>enriched form of
>> user interaction that makes learning to use a computer easier.
>With the
>> software service, developers can enhance the user interface of
>their
>> applications and Web pages with interactive personalities in the
>form of
>> animated characters.
>>
>> This feature is preinstalled on Win2k/XP and allows loading of
>remote
>> character data via HTTP through Internet Explorer. Microsoft
>actually
>> utilizes a custom compression algorithm to compress the
>character data file
>> (.acf) which we presume is to speed up the distribution over
>network.
>>
>> A security researcher of COSEINC Vulnerability Research Lab has
>discovered
>> that Microsoft Agent has a heap overflow vulnerability. This
>vulnerability
>> is triggered when Microsoft Agent parses the malformed character
>file in its
>> uncompressed state in memory, by having an overly large value in
>a length
>> field. This will lead to an integer overflow during the
>allocation of
>> buffer. Subsequently, when data is copied to the buffer, the
>heap overflow
>> will occur. The result is possible remote code execution.
>>
>> Technical Details:
>> The vulnerability exists in the ReadWideString function in
>agentdpv.dll:
>>
>> 711a2cc4 mov eax,[ebp+0xc]
>> 711a2cc7 cmp eax,ebx
>> 711a2cc9 jz agentdpv!ReadWideStringW+0x6b (711a2d0e)
>> 711a2ccb lea eax,[eax+eax+0x2]
>> 711a2ccf push eax
>> 711a2cd0 call agentdpv!operator new (711aaa6c)
>>
>> The .acf format when uncompressed in memory, stores strings with
>their
>> lengths prepended to them. To trigger the vulnerability, a large
>value
>> 7FFFFFFF can be set in the length field of a string before
>compression takes
>> place to create a malformed .acf file (This can be done using
>the Microsoft-
>> supplied Agent Character Editor and editing the memory contents
>when
>> creating the .acf file). When Microsoft Agent parses the .acf
>file, this
>> length is read after uncompressing the file in memory:
>>
>> 711a2cc4 mov eax,[ebp+0xc] ; length of string
>>
>> An integer overflow occurs presumably during the calculation of
>the size of
>> the memory to allocate for a widestring using the supplied
>length, resulting
>> in an allocation of 0 bytes:
>>
>> 711a2ccb lea eax,[eax+eax+0x2]
>> 711a2ccf push eax
>> 711a2cd0 call agentdpv!operator new (711aaa6c)
>>
>> Sometime after, the string will be read from memory allocated
>earlier and
>> copied to the buffer leading to the overflow and corrupting the
>heap.
>>
>> 711a2ce8 push ebx
>> 711a2ce9 add edx,edx
>> 711a2ceb push edx
>> 711a2cec push eax
>> 711a2ced push edi
>> 711a2cee call dword ptr [ecx+0xc]{ole32!CMemStm::Read
>(771e7a1f)}
>>
>> Notes:
>> The string has been earlier written (together with other data)
>to a
>> temporary buffer as a result of the uncompressing procedure. The
>2nd DWORD
>> in the .acf file specifies the total size of the file in its
>uncompressed
>> state and is used internally to allocate the required memory for
>the
>> temporary buffer.
>>
>> The number of bytes to copy from this temporary buffer is
>apparently
>> determined by subtracting from the total size, the size of
>previous data
>> chunks and does not utilize the supplied string length.
>>
>> Hence, the amount of overflow can be controlled by simply using
>a string of
>> the desired length. This is why the large length of 7FFFFFFF
>does not result
>> in continuous copying leading to access violation (usually in
>the case of an
>> integer overflow). Consequently, an arbitrary 4-byte overwrite
>will occur
>> resulting in possible code execution.
>>
>> Vendor Status:
>> Microsoft has released a patch for this vulnerability. The patch
>is
>> available at:
>> http://www.microsoft.com/technet/security/bulletin/ms06-068.mspx
>>
>> Credit:
>> This vulnerability was discovered by Willow, a Windows security
>researcher
>> of the COSEINC Vulnerability Research Lab (VRL).
>>
>> Disclaimer:
>> The information within this paper may change without notice. Use
>of this
>> information constitutes acceptance for use in an AS IS
>condition. There are
>> no warranties, implied or express, with regard to this
>information. In no
>> event shall the author or the company be liable for any direct
>or indirect
>> damages whatsoever arising out of or in connection with the use
>or spread of
>> this information. Any use of this information is at the user's
>own risk.
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>> End of Full-Disclosure Digest, Vol 23, Issue 56
>> ***********************************************
>>
>
>-----------------------------------------
>Email sent from www.ntlworld.com
>Virus-checked using McAfee(R) Software
>Visit www.ntlworld.com/security for more information
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsored by Secunia - http://secunia.com/
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5
wpwEAQECAAYFAkW/gUYACgkQgSMOKd40iZg6UAP/WLx0GdnlvJQVbVzxFZ5k2pW6Dzsa
AGIDNEzqkrVXEff2rO7QyPRTNchJ6iTAYoF52L42/PiYbJ4iwF9alMnyU2XEIhH1hnRj
aaQislNzxVnCYdWzor8FRNU3wHK4Ojo1K5vi7Rl+90Ai3VXchEhfC5AKU5Zjx24jLIbN
ogW0M6o=
=Xx0l
-----END PGP SIGNATURE-----
Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480
Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists