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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 30 Jan 2007 13:18:25 +0000
From: <douglas.graham@...world.com>
To: <full-disclosure@...ts.grok.org.uk>
Subject: Re: Full-Disclosure Digest, Vol 23, Issue 56


> Hello. I am Douglas Graham’s 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_configuration_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/networking_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_configuration_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/networking_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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ