Re: 3rd party patch for XP for MS09-048?
http://www.computerworld.com/s/article/9138007/Microsoft_No_TCP_IP_patches_for_you_XP http://edge.technet.com/Media/MSRC-Monthly-Security-Bulletin-Webcast-September-2009/ Jeffrey Walton wrote: Hi Aras, Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, Can you cite a reference? Unless Microsoft has changed their end of life policy [1], XP should be patched for security vulnerabilities until about 2014. Both XP Home and XP Pro's mainstream support ended in 4/2009, but extended support ends in 4/2014 [2]. Given that we know the end of extended support, take a look at bullet 17 of [1]: 17. What is the Security Update policy? Security updates will be available through the end of the Extended Support phase (five years of Mainstream Support plus five years of the Extended Support) at no additional cost for most products. Security updates will be posted on the Microsoft Update Web site during both the Mainstream and the Extended Support phase. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... Not at all. Jeff [1] http://support.microsoft.com/gp/lifepolicy [2] http://support.microsoft.com/gp/lifeselect On Tue, Sep 15, 2009 at 2:46 PM, Aras "Russ" Memisyazici wrote: Hello All: Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, I'm now curious to find out whether or not any brave souls out there are already working or willing to work on an open-source patch to remediate the issue within XP. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... I would just like to hear the thoughts of the true experts subscribed to these lists :) No harm in that is there? Aras "Russ" Memisyazici Systems Administrator Virginia Tech
Re: 3rd party patch for XP for MS09-048?
Read the bulletin. There's no patch. It is deemed by Microsoft to be of low impact and thus no patch has been built. Jeffrey Walton wrote: Hi Aras, Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, Can you cite a reference? Unless Microsoft has changed their end of life policy [1], XP should be patched for security vulnerabilities until about 2014. Both XP Home and XP Pro's mainstream support ended in 4/2009, but extended support ends in 4/2014 [2]. Given that we know the end of extended support, take a look at bullet 17 of [1]: 17. What is the Security Update policy? Security updates will be available through the end of the Extended Support phase (five years of Mainstream Support plus five years of the Extended Support) at no additional cost for most products. Security updates will be posted on the Microsoft Update Web site during both the Mainstream and the Extended Support phase. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... Not at all. Jeff [1] http://support.microsoft.com/gp/lifepolicy [2] http://support.microsoft.com/gp/lifeselect On Tue, Sep 15, 2009 at 2:46 PM, Aras "Russ" Memisyazici wrote: Hello All: Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, I'm now curious to find out whether or not any brave souls out there are already working or willing to work on an open-source patch to remediate the issue within XP. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... I would just like to hear the thoughts of the true experts subscribed to these lists :) No harm in that is there? Aras "Russ" Memisyazici Systems Administrator Virginia Tech
Re: 3rd party patch for XP for MS09-048?
Microsoft Security Bulletin MS09-048 - Critical: Vulnerabilities in Windows TCP/IP Could Allow Remote Code Execution (967723): http://www.microsoft.com/technet/security/Bulletin/MS09-048.mspx If Windows XP is listed as an affected product, why is Microsoft not issuing an update for it?By default, Windows XP Service Pack 2, Windows XP Service Pack 3, and Windows XP Professional x64 Edition Service Pack 2 do not have a listening service configured in the client firewall and are therefore not affected by this vulnerability. Windows XP Service Pack 2 and later operating systems include a stateful host firewall that provides protection for computers against incoming traffic from the Internet or from neighboring network devices on a private network. The impact of a denial of service attack is that a system would become unresponsive due to memory consumption. However, a successful attack requires a sustained flood of specially crafted TCP packets, and the system will recover once the flood ceases. This makes the severity rating Low for Windows XP. Windows XP is not affected by CVE-2009-1925. Customers running Windows XP are at reduced risk, and Microsoft recommends they use the firewall included with the operating system, or a network firewall, to block access to the affected ports and limit the attack surface from untrusted networks. Susan Bradley wrote: Read the bulletin. There's no patch. It is deemed by Microsoft to be of low impact and thus no patch has been built. Jeffrey Walton wrote: Hi Aras, Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, Can you cite a reference? Unless Microsoft has changed their end of life policy [1], XP should be patched for security vulnerabilities until about 2014. Both XP Home and XP Pro's mainstream support ended in 4/2009, but extended support ends in 4/2014 [2]. Given that we know the end of extended support, take a look at bullet 17 of [1]: 17. What is the Security Update policy? Security updates will be available through the end of the Extended Support phase (five years of Mainstream Support plus five years of the Extended Support) at no additional cost for most products. Security updates will be posted on the Microsoft Update Web site during both the Mainstream and the Extended Support phase. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... Not at all. Jeff [1] http://support.microsoft.com/gp/lifepolicy [2] http://support.microsoft.com/gp/lifeselect On Tue, Sep 15, 2009 at 2:46 PM, Aras "Russ" Memisyazici wrote: Hello All: Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, I'm now curious to find out whether or not any brave souls out there are already working or willing to work on an open-source patch to remediate the issue within XP. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... I would just like to hear the thoughts of the true experts subscribed to these lists :) No harm in that is there? Aras "Russ" Memisyazici Systems Administrator Virginia Tech
Re: 3rd party patch for XP for MS09-048?
Reference: http://www.computerworld.com/s/article/9138007/Microsoft_No_TCP_IP_patches_for_you_XP MS claims the patch would require to much overhaul of XP to make it worth it, and they may be right. Who knows how many applications might break that were designed for XP if they have to radically change the TCP/IP stack. Now, I don't know if the MS speak is true, but it certainly sounds like it is not going to be patched. The other side of the MS claim is that a properly-firewalled XP system would not be vulnerable to a DOS anyway, so a patch shouldn't be necessary. -Eric Original Message Subject: Re: 3rd party patch for XP for MS09-048? From: Jeffrey Walton To: nowh...@devnull.com Cc: bugtraq@securityfocus.com, full-disclos...@lists.grok.org.uk Date: 9/15/09 3:49 PM > Hi Aras, > > >> Given that M$ has officially shot-down all current Windows XP users by not >> issuing a patch for a DoS level issue, >> > Can you cite a reference? > > Unless Microsoft has changed their end of life policy [1], XP should > be patched for security vulnerabilities until about 2014. Both XP Home > and XP Pro's mainstream support ended in 4/2009, but extended support > ends in 4/2014 [2]. Given that we know the end of extended support, > take a look at bullet 17 of [1]: > > 17. What is the Security Update policy? > > Security updates will be available through the end of the Extended > Support phase (five years of Mainstream Support plus five years of > the Extended Support) at no additional cost for most products. > Security updates will be posted on the Microsoft Update Web site > during both the Mainstream and the Extended Support phase. > > >> I realize some of you might be tempted to relay the M$ BS about "not being >> feasible because it's a lot of work" rhetoric... >> > Not at all. > > Jeff > > [1] http://support.microsoft.com/gp/lifepolicy > [2] http://support.microsoft.com/gp/lifeselect > > On Tue, Sep 15, 2009 at 2:46 PM, Aras "Russ" Memisyazici > wrote: > >> Hello All: >> >> Given that M$ has officially shot-down all current Windows XP users by not >> issuing a patch for a DoS level issue, I'm now curious to find out whether >> or not any brave souls out there are already working or willing to work on >> an open-source patch to remediate the issue within XP. >> >> I realize some of you might be tempted to relay the M$ BS about "not being >> feasible because it's a lot of work" rhetoric... I would just like to hear >> the thoughts of the true experts subscribed to these lists :) >> >> No harm in that is there? >> >> Aras "Russ" Memisyazici >> Systems Administrator >> Virginia Tech >> >> >> -- Eric C. Lukens IT Security Policy and Risk Assessment Analyst ITS-Network Services Curris Business Building 15 University of Northern Iowa Cedar Falls, IA 50614-0121 319-273-7434 http://www.uni.edu/elukens/ http://weblogs.uni.edu/elukens/
[SECURITY] [DSA 1888-1] New openssl packages deprecate MD2 hash signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1888-1 secur...@debian.org http://www.debian.org/security/ Moritz Muehlenhoff September 15, 2009http://www.debian.org/security/faq - Package: openssl, openssl097 Vulnerability : cryptographic weakness Problem type : remote Debian-specific: no CVE Id(s) : CVE-2009-2409 Certificates with MD2 hash signatures are no longer accepted by OpenSSL, since they're no longer considered cryptographically secure. For the stable distribution (lenny), this problem has been fixed in version 0.9.8g-15+lenny5. For the old stable distribution (etch), this problem has been fixed in version 0.9.8c-4etch9 for openssl and version 0.9.7k-3.1etch5 for openssl097. The OpenSSL 0.9.8 update for oldstable (etch) also provides updated packages for multiple denial of service vulnerabilities in the Datagram Transport Layer Security implementation. These fixes were already provided for Debian stable (Lenny) in a previous point update. The OpenSSL 0.9.7 package from oldstable (Etch) is not affected. (CVE-2009-1377, CVE-2009-1378, CVE-2009-1379, CVE-2009-1386 and CVE-2009-1387) For the unstable distribution (sid), this problem has been fixed in version 0.9.8k-5. We recommend that you upgrade your openssl packages. Upgrade instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 4.0 alias etch - --- Oldstable updates are available for alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/o/openssl097/openssl097_0.9.7k-3.1etch5.dsc Size/MD5 checksum: 1417 cfeda0aa5b691a5745475692c5d95023 http://security.debian.org/pool/updates/main/o/openssl097/openssl097_0.9.7k-3.1etch5.diff.gz Size/MD5 checksum:35983 d36ced1a9b6bc9fb473142df040a06d6 http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.8c-4etch9.dsc Size/MD5 checksum: 1455 853078a1ba61d986d0862b7052e6a47b http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.8c.orig.tar.gz Size/MD5 checksum: 3313857 78454bec556bcb4c45129428a766c886 http://security.debian.org/pool/updates/main/o/openssl097/openssl097_0.9.7k.orig.tar.gz Size/MD5 checksum: 3292692 be6bba1d67b26eabb48cf1774925416f http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.8c-4etch9.diff.gz Size/MD5 checksum:59037 1d168f6505755d3d5b2cc5c8dfc4a314 alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.8_0.9.8c-4etch9_alpha.deb Size/MD5 checksum: 2623244 6d978b3c3271793c8e7af4805335186c http://security.debian.org/pool/updates/main/o/openssl097/libssl0.9.7_0.9.7k-3.1etch5_alpha.deb Size/MD5 checksum: 2209790 7b1bd54453a93ae2b20d25abf8e0187a http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.8c-4etch9_alpha.deb Size/MD5 checksum: 2556932 aff297a5754a34193d35e1e7bb1de5e5 http://security.debian.org/pool/updates/main/o/openssl097/libssl0.9.7-dbg_0.9.7k-3.1etch5_alpha.deb Size/MD5 checksum: 3822402 2d51057194c55709f258303f9eb5634d http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.8c-4etch9_alpha.deb Size/MD5 checksum: 1015184 1a7ee5f6d57cc91aaee2df7efbed7e03 http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.8-dbg_0.9.8c-4etch9_alpha.deb Size/MD5 checksum: 4561710 6e24f6d818c1c6e791f3b457e9d025cd http://security.debian.org/pool/updates/main/o/openssl/libcrypto0.9.8-udeb_0.9.8c-4etch9_alpha.udeb Size/MD5 checksum: 677314 840e921e5eb158208331c1eb4e546453 amd64 architecture (AMD x86_64 (AMD64)) http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.8c-4etch9_amd64.deb Size/MD5 checksum: 2188696 730e51554bee77b38922ab4968f7bd8f http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.8_0.9.8c-4etch9_amd64.deb Size/MD5 checksum: 891856 373b14c8d5d44eba8e2a704d29621e4e http://security.debian.org/pool/updates/main/o/openssl097/libssl0.9.7-dbg_0.9.7k-3.1etch5_amd64.deb Size/MD5 checksum: 1328748 32e707b77f010c26690d0d170b3b8c71 http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.8-dbg_0.9.8c-4etch9_amd64.deb Size/MD5 checksum: 1655940 94723e6134595ff2a407ab3cb99c24c9 http://security.debian.org/pool/updates/main/o/op
Re: Improper Authentication Mechanism in 3Com Wireless8760 Dual Radio 11a/b/g Poe Access Point
Hi Yossi, Are you doing something funky with your IP address, e.g., NAT'ed/short DHCP lease? The reason I ask is because in 2008, Adrian Pastor stated authentication in the 3Com Wireless 8760 was linked to the source IP address [1]. It may well be the case (as you have discovered) that it allows arbitrary IP addresses to access the config once an administrator has authentication... However, I just wanted to hit this badboy up incase there was some confusion. Cheers, Tom [1] http://securityreason.com/wlb_show/WLB-2008110039 On Tue, 15 Sep 2009 22:27:31 +0300, Yossi Yakubov wrote: > Hi > My name is Yossi Yakubov and i am a security researcher. Recently me > and my collegues found the following vulnerability in the 3Com > Wireless8760 web administration interface: > > If one user is authenticated to the web interface, other users can > access to internal pages without further authentication. That means > that one opened Session is enough between the user and web > administration , and other users can also access to the web > administration interface. > > Malicious user can wait until ones logins to the interface and then he > can access and administer 3Com Wireless8760 Access Point without > further authentication. Among different operations the malicious user > can cause to Denial of Service (Dos) attack to the entire network by > changing the configuration such as IP addresses. > > FYI > > Waiting for your review > > Best Regards > > Yossi Yakubov
Re: 3rd party patch for XP for MS09-048?
Hi Susan, > Read the bulletin. There's no patch. It is deemed by Microsoft to be of > low impact and thus no patch has been built. I don't know how I missed that XP/SP2 and above were not being patched. It appears that my two references are worhtless... I used to use them in position papers! * http://support.microsoft.com/gp/lifepolicy * http://support.microsoft.com/gp/lifeselect Jeff On Tue, Sep 15, 2009 at 5:24 PM, Susan Bradley wrote: > Read the bulletin. There's no patch. It is deemed by Microsoft to be of > low impact and thus no patch has been built. > > Jeffrey Walton wrote: >> >> Hi Aras, >> >> >>> >>> Given that M$ has officially shot-down all current Windows XP users by >>> not >>> issuing a patch for a DoS level issue, >>> >> >> Can you cite a reference? >> >> Unless Microsoft has changed their end of life policy [1], XP should >> be patched for security vulnerabilities until about 2014. Both XP Home >> and XP Pro's mainstream support ended in 4/2009, but extended support >> ends in 4/2014 [2]. Given that we know the end of extended support, >> take a look at bullet 17 of [1]: >> >> 17. What is the Security Update policy? >> >> Security updates will be available through the end of the Extended >> Support phase (five years of Mainstream Support plus five years of >> the Extended Support) at no additional cost for most products. >> Security updates will be posted on the Microsoft Update Web site >> during both the Mainstream and the Extended Support phase. >> >> >>> >>> I realize some of you might be tempted to relay the M$ BS about "not >>> being >>> feasible because it's a lot of work" rhetoric... >>> >> >> Not at all. >> >> Jeff >> >> [1] http://support.microsoft.com/gp/lifepolicy >> [2] http://support.microsoft.com/gp/lifeselect >> >> On Tue, Sep 15, 2009 at 2:46 PM, Aras "Russ" Memisyazici >> wrote: >> >>> >>> Hello All: >>> >>> Given that M$ has officially shot-down all current Windows XP users by >>> not >>> issuing a patch for a DoS level issue, I'm now curious to find out >>> whether >>> or not any brave souls out there are already working or willing to work >>> on >>> an open-source patch to remediate the issue within XP. >>> >>> I realize some of you might be tempted to relay the M$ BS about "not >>> being >>> feasible because it's a lot of work" rhetoric... I would just like to >>> hear >>> the thoughts of the true experts subscribed to these lists :) >>> >>> No harm in that is there? >>> >>> Aras "Russ" Memisyazici >>> Systems Administrator >>> Virginia Tech >>> >>> >>> >> >> > >
Re: 3rd party patch for XP for MS09-048?
On 16/09/09 8:49 AM, Jeffrey Walton wrote: Hi Aras, Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, Can you cite a reference? http://tech.slashdot.org/article.pl?sid=09/09/15/0131209 -- Cheers, Matt Riddell Director ___ http://www.venturevoip.com/news.php (Daily Asterisk News) http://www.venturevoip.com/st.php (SmoothTorque Predictive Dialer) http://www.venturevoip.com/c3.php (ConduIT3 PABX Systems)
Re: 3rd party patch for XP for MS09-048?
It's not that they aren't supported per se, just that Microsoft has deemed the impact of DOS to be low, the ability to patch that platform impossible/difficult and thus have make a risk calculation accordingly. Sometimes the architecture is what it is. Jeffrey Walton wrote: Hi Susan, Read the bulletin. There's no patch. It is deemed by Microsoft to be of low impact and thus no patch has been built. I don't know how I missed that XP/SP2 and above were not being patched. It appears that my two references are worhtless... I used to use them in position papers! * http://support.microsoft.com/gp/lifepolicy * http://support.microsoft.com/gp/lifeselect Jeff On Tue, Sep 15, 2009 at 5:24 PM, Susan Bradley wrote: Read the bulletin. There's no patch. It is deemed by Microsoft to be of low impact and thus no patch has been built. Jeffrey Walton wrote: Hi Aras, Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, Can you cite a reference? Unless Microsoft has changed their end of life policy [1], XP should be patched for security vulnerabilities until about 2014. Both XP Home and XP Pro's mainstream support ended in 4/2009, but extended support ends in 4/2014 [2]. Given that we know the end of extended support, take a look at bullet 17 of [1]: 17. What is the Security Update policy? Security updates will be available through the end of the Extended Support phase (five years of Mainstream Support plus five years of the Extended Support) at no additional cost for most products. Security updates will be posted on the Microsoft Update Web site during both the Mainstream and the Extended Support phase. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... Not at all. Jeff [1] http://support.microsoft.com/gp/lifepolicy [2] http://support.microsoft.com/gp/lifeselect On Tue, Sep 15, 2009 at 2:46 PM, Aras "Russ" Memisyazici wrote: Hello All: Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, I'm now curious to find out whether or not any brave souls out there are already working or willing to work on an open-source patch to remediate the issue within XP. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... I would just like to hear the thoughts of the true experts subscribed to these lists :) No harm in that is there? Aras "Russ" Memisyazici Systems Administrator Virginia Tech
Re: Re: 3rd party patch for XP for MS09-048?
As I understand the bulletin, Microsoft will not be releasing MS09-048 patches for XP because, by default, it runs no listening services or the windows firewall can protect it. Quoting http://www.microsoft.com/technet/security/bulletin/MS09-048.mspx "If Windows XP is listed as an affected product, why is Microsoft not issuing an update for it? By default, Windows XP Service Pack 2, Windows XP Service Pack 3, and Windows XP Professional x64 Edition Service Pack 2 do not have a listening service configured in the client firewall and are therefore not affected by this vulnerability. Windows XP Service Pack 2 and later operating systems include a stateful host firewall that provides protection for computers against incoming traffic from the Internet or from neighboring network devices on a private network. ... Customers running Windows XP are at reduced risk, and Microsoft recommends they use the firewall included with the operating system, or a network firewall, to block access to the affected ports and limit the attack surface from untrusted networks." -eg
[security bulletin] HPSBUX02458 SSRT090104 rev.1 - HP-UX Running bootpd, Remote Denial of Service (DoS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SUPPORT COMMUNICATION - SECURITY BULLETIN Document ID: c01866324 Version: 1 HPSBUX02458 SSRT090104 rev.1 - HP-UX Running bootpd, Remote Denial of Service (DoS) NOTICE: The information in this Security Bulletin should be acted upon as soon as possible. Release Date: 2009-09-14 Last Updated: 2009-09-14 Potential Security Impact: Remote Denial of Service (DoS) Source: Hewlett-Packard Company, HP Software Security Response Team VULNERABILITY SUMMARY A potential security vulnerability has been identified with HP-UX running bootpd. The vulnerability could be exploited remotely to create a Denial of Service (DoS). References: CVE-2009-2679 SUPPORTED SOFTWARE VERSIONS*: ONLY impacted versions are listed. HP-UX B.11.11, B.11.23 and HP-UX B.11.31 running bootpd BACKGROUND CVSS 2.0 Base Metrics === Reference Base Vector Base Score CVE-2009-2679(AV:R/AC:L/Au:N/C:N/I:N/A:C) 7.8 === Information on CVSS is documented in HP Customer Notice: HPSN-2008-002 RESOLUTION HP has provided the following patches to resolve this vulnerability. The patches are available from the following location http://itrc.hp.com HP-UX Release Patch ID B.11.11 (11i v1) PHNE_39700 or subsequent B.11.23 (11i v2) PHNE_39668 or subsequent B.11.31 (11i v3) PHNE_39443 or subsequent MANUAL ACTIONS: No PRODUCT SPECIFIC INFORMATION HP-UX Software Assistant: HP-UX Software Assistant is an enhanced application that replaces HP-UX Security Patch Check. It analyzes all Security Bulletins issued by HP and lists recommended actions that may apply to a specific HP-UX system. It can also download patches and create a depot automatically. For more information see: https://www.hp.com/go/swa The following text is for use by the HP-UX Software Assistant. AFFECTED VERSIONS HP-UX B.11.11 == InternetSrvcs.INETSVCS2-BOOT action: install PHNE_39700 or subsequent HP-UX B.11.23 == InternetSrvcs.INETSVCS2-BOOT action: install PHNE_39668 or subsequent HP-UX B.11.31 == DHCPv4.DHCPV4-RUN action: install PHNE_39443 or subsequent END AFFECTED VERSIONS HISTORY Version:1 (rev.1) - 14 September 2009 Initial release Third Party Security Patches: Third party security patches that are to be installed on systems running HP software products should be applied in accordance with the customer's patch management policy. Support: For further information, contact normal HP Services support channel. Report: To report a potential security vulnerability with any HP supported product, send Email to: security-al...@hp.com It is strongly recommended that security related information being communicated to HP be encrypted using PGP, especially exploit information. To get the security-alert PGP key, please send an e-mail message as follows: To: security-al...@hp.com Subject: get key Subscribe: To initiate a subscription to receive future HP Security Bulletins via Email: http://h30046.www3.hp.com/driverAlertProfile.php?regioncode=NA&langcode=USENG&jumpid=in_SC-GEN__driverITRC&topiccode=ITRC On the web page: ITRC security bulletins and patch sign-up Under Step1: your ITRC security bulletins and patches -check ALL categories for which alerts are required and continue. Under Step2: your ITRC operating systems -verify your operating system selections are checked and save. To update an existing subscription: http://h30046.www3.hp.com/subSignIn.php Log in on the web page: Subscriber's choice for Business: sign-in. On the web page: Subscriber's Choice: your profile summary - use Edit Profile to update appropriate sections. To review previously published Security Bulletins visit: http://www.itrc.hp.com/service/cki/secBullArchive.do * The Software Product Category that this Security Bulletin relates to is represented by the 5th and 6th characters of the Bulletin number in the title: GN = HP General SW MA = HP Management Agents MI = Misc. 3rd Party SW MP = HP MPE/iX NS = HP NonStop Servers OV = HP OpenVMS PI = HP Printing & Imaging ST = HP Storage SW TL = HP Trusted Linux TU = HP Tru64 UNIX UX = HP-UX VV = HP VirtualVault System management and security procedures must be reviewed frequently to maintain system integrity. HP is continually reviewing and enhancing the security features of software products to provide customers with current secure solutions. "HP is broadly distributing this Security Bulletin in order to bring to the attention of users of the affected HP products the important security information contained in this Bulletin. HP recommends that all users determine the applicability of this information to their individual situations and take appropriate action. HP does not warrant that this information is necessarily accurate or complete for all user situations and, consequent
RE: [Full-disclosure] 3rd party patch for XP for MS09-048?
Thanks for the link. The problem here is that not enough information is given, and what IS given is obviously watered down to the point of being ineffective. The quote that stands out most for me: During the Q&A, however, Windows users repeatedly asked Microsoft's security team to explain why it wasn't patching XP, or if, in certain scenarios, their machines might be at risk. "We still use Windows XP and we do not use Windows Firewall," read one of the user questions. "We use a third-party vendor firewall product. Even assuming that we use the Windows Firewall, if there are services listening, such as remote desktop, wouldn't then Windows XP be vulnerable to this?" "Servers are a more likely target for this attack, and your firewall should provide additional protections against external exploits," replied Stone and Bryant. If an employee managing a product that my company owned gave answers like that to a public interview with Computerworld, they would be in deep doo. First off, my default install of XP Pro SP2 has remote assistance inbound, and once you join to a domain, you obviously accept necessary domain traffic. This "no inbound traffic by default so you are not vulnerable" line is crap. It was a direct question - "If RDP is allowed through the firewall, are we vulnerable?" A:"Great question. Yes, servers are the target. A firewall should provide added protection, maybe. Rumor is that's what they are for. Not sure really. What was the question again?" You don't get "trustworthy" by not answering people's questions, particularly when they are good, obvious questions. Just be honest about it. "Yes, XP is vulnerable to a DOS. Your firewall might help, but don't bet on it. XP code is something like 15 years old now, and we're not going to change it. That's the way it is, sorry. Just be glad you're using XP and not 2008/vista or you'd be patching your arse off right now." If MSFT thinks they are mitigating public opinion issues by side-stepping questions and not fully exposing the problems, they are wrong. This just makes it worse. That's the long answer. The short answer is "XP is vulnerable to a DoS, and a patch is not being offered." t > -Original Message- > From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- > disclosure-boun...@lists.grok.org.uk] On Behalf Of Eric C. Lukens > Sent: Tuesday, September 15, 2009 2:37 PM > To: bugtraq@securityfocus.com > Cc: full-disclos...@lists.grok.org.uk > Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? > > Reference: > > http://www.computerworld.com/s/article/9138007/Microsoft_No_TCP_IP_patc > hes_for_you_XP > > MS claims the patch would require to much overhaul of XP to make it > worth it, and they may be right. Who knows how many applications might > break that were designed for XP if they have to radically change the > TCP/IP stack. Now, I don't know if the MS speak is true, but it > certainly sounds like it is not going to be patched. > > The other side of the MS claim is that a properly-firewalled XP system > would not be vulnerable to a DOS anyway, so a patch shouldn't be > necessary. > > -Eric > > Original Message > Subject: Re: 3rd party patch for XP for MS09-048? > From: Jeffrey Walton > To: nowh...@devnull.com > Cc: bugtraq@securityfocus.com, full-disclos...@lists.grok.org.uk > Date: 9/15/09 3:49 PM > > Hi Aras, > > > > > >> Given that M$ has officially shot-down all current Windows XP users > by not > >> issuing a patch for a DoS level issue, > >> > > Can you cite a reference? > > > > Unless Microsoft has changed their end of life policy [1], XP should > > be patched for security vulnerabilities until about 2014. Both XP > Home > > and XP Pro's mainstream support ended in 4/2009, but extended support > > ends in 4/2014 [2]. Given that we know the end of extended support, > > take a look at bullet 17 of [1]: > > > > 17. What is the Security Update policy? > > > > Security updates will be available through the end of the > Extended > > Support phase (five years of Mainstream Support plus five years > of > > the Extended Support) at no additional cost for most products. > > Security updates will be posted on the Microsoft Update Web site > > during both the Mainstream and the Extended Support phase. > > > > > >> I realize some of you might be tempted to relay the M$ BS about "not > being > >> feasible because it's a lot of work" rhetoric... > >> > > Not at all. > > > > Jeff > > > > [1] http://support.microsoft.com/gp/lifepolicy > > [2] http://support.microsoft.com/gp/lifeselect > > > > On Tue, Sep 15, 2009 at 2:46 PM, Aras "Russ" Memisyazici > > wrote: > > > >> Hello All: > >> > >> Given that M$ has officially shot-down all current Windows XP users > by not > >> issuing a patch for a DoS level issue, I'm now curious to find out > whether > >> or not any brave souls out there are already working or willing to > work o
ANNOUNCE: RFIDIOt release - v0.z - 16th September, 2009
Hi, Since I seem to have missed a version, here are the CHANGES for .y & .z: v0.y fix support for ACS PCSC-2 devices (e.g. ACR 122U) add writelfx.py - test write LF devices fix 3DES key setting for ID cards in mrpkey.py allow missing files to be skipped if running in files mode in mrpkey.py v0.z add xorcheck.py - search for valid final byte of rolling LRC [input from Henryk Plötz] add transit.py - program Q5 with FDI Matalec 'TRANSIT 500' or 'TRANSIT 999' standard UID [input from Proxmark Community] Download here: http://www.rfidiot.org/ cheers, Adam -- Adam Laurie Tel: +44 (0) 20 7993 2690 Suite 117 Fax: +44 (0) 1308 867 949 61 Victoria Road Surbiton Surrey mailto:a...@algroup.co.uk KT6 4JX http://rfidiot.org
RE: [Full-disclosure] 3rd party patch for XP for MS09-048?
I agree that the FAQ explanation in the advisory is vague about what protection the firewall provides. One clue I would infer about it is that they rated this a "Low" threat. If it were vulnerable in the default configuration, with the firewall (or some other firewall) on, they probably would have rated it at least Medium. If I'm wrong about that then the "Low" rating is misleading. Larry Seltzer Contributing Editor, PC Magazine larry_selt...@ziffdavis.com http://blogs.pcmag.com/securitywatch/ -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Thor (Hammer of God) Sent: Wednesday, September 16, 2009 11:00 AM To: Eric C. Lukens; bugtraq@securityfocus.com Cc: full-disclos...@lists.grok.org.uk Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? Thanks for the link. The problem here is that not enough information is given, and what IS given is obviously watered down to the point of being ineffective. The quote that stands out most for me: During the Q&A, however, Windows users repeatedly asked Microsoft's security team to explain why it wasn't patching XP, or if, in certain scenarios, their machines might be at risk. "We still use Windows XP and we do not use Windows Firewall," read one of the user questions. "We use a third-party vendor firewall product. Even assuming that we use the Windows Firewall, if there are services listening, such as remote desktop, wouldn't then Windows XP be vulnerable to this?" "Servers are a more likely target for this attack, and your firewall should provide additional protections against external exploits," replied Stone and Bryant. If an employee managing a product that my company owned gave answers like that to a public interview with Computerworld, they would be in deep doo. First off, my default install of XP Pro SP2 has remote assistance inbound, and once you join to a domain, you obviously accept necessary domain traffic. This "no inbound traffic by default so you are not vulnerable" line is crap. It was a direct question - "If RDP is allowed through the firewall, are we vulnerable?" A:"Great question. Yes, servers are the target. A firewall should provide added protection, maybe. Rumor is that's what they are for. Not sure really. What was the question again?" You don't get "trustworthy" by not answering people's questions, particularly when they are good, obvious questions. Just be honest about it. "Yes, XP is vulnerable to a DOS. Your firewall might help, but don't bet on it. XP code is something like 15 years old now, and we're not going to change it. That's the way it is, sorry. Just be glad you're using XP and not 2008/vista or you'd be patching your arse off right now." If MSFT thinks they are mitigating public opinion issues by side-stepping questions and not fully exposing the problems, they are wrong. This just makes it worse. That's the long answer. The short answer is "XP is vulnerable to a DoS, and a patch is not being offered." t > -Original Message- > From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- > disclosure-boun...@lists.grok.org.uk] On Behalf Of Eric C. Lukens > Sent: Tuesday, September 15, 2009 2:37 PM > To: bugtraq@securityfocus.com > Cc: full-disclos...@lists.grok.org.uk > Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? > > Reference: > > http://www.computerworld.com/s/article/9138007/Microsoft_No_TCP_IP_patc > hes_for_you_XP > > MS claims the patch would require to much overhaul of XP to make it > worth it, and they may be right. Who knows how many applications might > break that were designed for XP if they have to radically change the > TCP/IP stack. Now, I don't know if the MS speak is true, but it > certainly sounds like it is not going to be patched. > > The other side of the MS claim is that a properly-firewalled XP system > would not be vulnerable to a DOS anyway, so a patch shouldn't be > necessary. > > -Eric > > Original Message > Subject: Re: 3rd party patch for XP for MS09-048? > From: Jeffrey Walton > To: nowh...@devnull.com > Cc: bugtraq@securityfocus.com, full-disclos...@lists.grok.org.uk > Date: 9/15/09 3:49 PM > > Hi Aras, > > > > > >> Given that M$ has officially shot-down all current Windows XP users > by not > >> issuing a patch for a DoS level issue, > >> > > Can you cite a reference? > > > > Unless Microsoft has changed their end of life policy [1], XP should > > be patched for security vulnerabilities until about 2014. Both XP > Home > > and XP Pro's mainstream support ended in 4/2009, but extended support > > ends in 4/2014 [2]. Given that we know the end of extended support, > > take a look at bullet 17 of [1]: > > > > 17. What is the Security Update policy? > > > > Security updates will be available through the end of the > Extended > > Support phase (five years of Mainstream Support plus five years > of > >
RE: [Full-disclosure] 3rd party patch for XP for MS09-048?
P.S. Anyone check to see if the default "XP Mode" VM you get for free with Win7 hyperv is vulnerable and what the implications are for a host running an XP vm that get's DoS'd are? I get the whole "XP code to too old to care" bit, but it seems odd to take that "old code" and re-market it around compatibility and re-distribute it with free downloads for Win7 while saying "we won't patch old code." t > -Original Message- > From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- > disclosure-boun...@lists.grok.org.uk] On Behalf Of Thor (Hammer of God) > Sent: Wednesday, September 16, 2009 8:00 AM > To: Eric C. Lukens; bugtraq@securityfocus.com > Cc: full-disclos...@lists.grok.org.uk > Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? > > Thanks for the link. The problem here is that not enough information > is given, and what IS given is obviously watered down to the point of > being ineffective. > > The quote that stands out most for me: > > During the Q&A, however, Windows users repeatedly asked Microsoft's > security team to explain why it wasn't patching XP, or if, in certain > scenarios, their machines might be at risk. "We still use Windows XP > and we do not use Windows Firewall," read one of the user questions. > "We use a third-party vendor firewall product. Even assuming that we > use the Windows Firewall, if there are services listening, such as > remote desktop, wouldn't then Windows XP be vulnerable to this?" > > "Servers are a more likely target for this attack, and your firewall > should provide additional protections against external exploits," > replied Stone and Bryant. > > > If an employee managing a product that my company owned gave answers > like that to a public interview with Computerworld, they would be in > deep doo. First off, my default install of XP Pro SP2 has remote > assistance inbound, and once you join to a domain, you obviously accept > necessary domain traffic. This "no inbound traffic by default so you > are not vulnerable" line is crap. It was a direct question - "If RDP > is allowed through the firewall, are we vulnerable?" A:"Great question. > Yes, servers are the target. A firewall should provide added > protection, maybe. Rumor is that's what they are for. Not sure > really. What was the question again?" > > You don't get "trustworthy" by not answering people's questions, > particularly when they are good, obvious questions. Just be honest > about it. "Yes, XP is vulnerable to a DOS. Your firewall might help, > but don't bet on it. XP code is something like 15 years old now, and > we're not going to change it. That's the way it is, sorry. Just be > glad you're using XP and not 2008/vista or you'd be patching your arse > off right now." > > If MSFT thinks they are mitigating public opinion issues by side- > stepping questions and not fully exposing the problems, they are wrong. > This just makes it worse. That's the long answer. The short answer is > "XP is vulnerable to a DoS, and a patch is not being offered." > > t > > > > > -Original Message- > > From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- > > disclosure-boun...@lists.grok.org.uk] On Behalf Of Eric C. Lukens > > Sent: Tuesday, September 15, 2009 2:37 PM > > To: bugtraq@securityfocus.com > > Cc: full-disclos...@lists.grok.org.uk > > Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? > > > > Reference: > > > > > http://www.computerworld.com/s/article/9138007/Microsoft_No_TCP_IP_patc > > hes_for_you_XP > > > > MS claims the patch would require to much overhaul of XP to make it > > worth it, and they may be right. Who knows how many applications > might > > break that were designed for XP if they have to radically change the > > TCP/IP stack. Now, I don't know if the MS speak is true, but it > > certainly sounds like it is not going to be patched. > > > > The other side of the MS claim is that a properly-firewalled XP > system > > would not be vulnerable to a DOS anyway, so a patch shouldn't be > > necessary. > > > > -Eric > > > > Original Message > > Subject: Re: 3rd party patch for XP for MS09-048? > > From: Jeffrey Walton > > To: nowh...@devnull.com > > Cc: bugtraq@securityfocus.com, full-disclos...@lists.grok.org.uk > > Date: 9/15/09 3:49 PM > > > Hi Aras, > > > > > > > > >> Given that M$ has officially shot-down all current Windows XP > users > > by not > > >> issuing a patch for a DoS level issue, > > >> > > > Can you cite a reference? > > > > > > Unless Microsoft has changed their end of life policy [1], XP > should > > > be patched for security vulnerabilities until about 2014. Both XP > > Home > > > and XP Pro's mainstream support ended in 4/2009, but extended > support > > > ends in 4/2014 [2]. Given that we know the end of extended support, > > > take a look at bullet 17 of [1]: > > > > > > 17. What is the Security Update policy? > > > > > > Security updates will be
Exploiting Chrome and Opera's inbuilt ATOM/RSS reader with Script Execution and more
Exploiting Chrome and Operas inbuilt ATOM/RSS reader with Script Execution
and more
-
For complete post (with images), please visit -
http://securethoughts.com/2009/09/exploiting-chrome-and-operas-inbuilt-atomr
ss-reader-with-script-execution-and-more/
=
SECURETHOUGHTS.COM ADVISORY
- CVE-ID: CVE-2009- (Chrome) {Pending}
- Release Date : September 15, 2009
- Severity : Medium to High
- Discovered by : Inferno
=
I. TITLE
-
Exploiting Chrome and Operas inbuilt ATOM/RSS reader with Script Execution
and more
II. VULNERABLE
-
Chrome all versions 2 and 3 (< 3.0.195.21)
Opera all versions - 9 and 10.
III. BACKGROUND
-
Back in 2006, there was interesting research done by James Holderness[1] and
James M. Snell[2] which uncovered a variety of XSS issues in various online
feed aggregator services (e.g. Feed Demon). The vulnerability arises from
the fact that it is not expected of RSS readers to render scripted content.
I want to extend that research by doing threat analysis on inbuilt feed
readers offered in most modern browsers. I have found Google Chrome (v2,3)
and Opera (v9,v10) to be vulnerable, while Internet Explorer(v7,8), Firefox
3.5 and Safari 4 are resilient to the exploits mentioned below.
IV. DESCRIPTION
-
Google Chrome and Operas inbuilt RSS/ATOM Reader renders untrusted
javascript in an RSS/ATOM feed.
Exploit Scenarios
1. Scenario 1
1. Attacker social engineers a victim user to visit a rss/atom feed
link pointing to his or her evil site.
2. Victim uses Google Chrome / Opera browser to view the feed.
3. Malicious javascript gets executed on victims browser. Examples
1. Modifies into a phishing page and asks user credentials
for subscribing to Google Reader / My.Opera.com
2. Searches users browser history for visited url list [3]
3. Scans users internal network with/without javascript [4]
2. Scenario 2
1. Both attacker and victim user have an account to a trusted
website.
2. Either
1. The trusted web site lets the attacker inject JavaScript
content into any section of the sites RSS or an Atom feed.
3. OR
1. The trusted website uses blacklist to block known
executable file types for scripted content. E.g. html, jsp, etc.
2. Attacker uploads a file with extension .rss/.atom/arbitary
extension preceded by .rss/.atom [e.g. .atom.tx]. Most widely used Apache
web server passes Content-Type as application/{atom/rss}+xml for all the
three cases automatically in default configuration.
3. Attacker convinces victim to visit the direct link to
uploaded file.
4. Victims cookies and other sensitive data gets sent to
attackers site.
5. Note: For Internet Explorer (v7,8), the task is easier
because it does automatic mime type detection. So, you can execute
javascript content in any file extension. E.g. click
http://securethoughts.com/security/rssatomxss/anyfile.tx. However, for other
browsers, Firefox 3.5, Safari 4, Opera 10 and Chrome 3, they dont support
this functionality (perhaps for security reasons). So, using such extensions
mentioned above can be used as a workaround for script execution in Opera
and Chrome browsers.
3. Scenario 3
1. Similar to Scenario 1, but exploit can be used for complete
control over feeds in the Opera browser.
V. PROOF OF CONCEPT
-
1. Exploit Scenario 1 [Testcases - 18 XSS for Chrome, 38 XSS for Opera]
1. Chrome:
http://securethoughts.com/security/rssatomxss/googlechromexss.atom [or .rss]
2. Opera:
http://securethoughts.com/security/rssatomxss/opera10xss.atom [or .rss]
2. Exploit Scenario 2
1. Include all in Scenario 1
2. Opera:
http://securethoughts.com/security/rssatomxss/opera10xss.atom.tx [Any
arbitary file extension at. E.g .tx, .tm]
3. Chrome:
http://securethoughts.com/security/rssatomxss/googlechromexss.atom.tx [Any
arbitary file extension at. E.g .tx, .tm]
3. Exploit Scenario 3
1. Details and PoC will be released after patch is provided by
Opera Security Team in next minor release.
For research purposes, you can try out the PoCs on these virtualized (and
vulnerable) versions of various browsers, without installing any bits on
your computer [5].
VI. FIX DESCRIPTION
-
Chrome: ATOM/RSS feed rendering is completely disabled by forcing a
text/plain MIME type [6]. If you need feed rendering, a good alternative is
FeedBurner which protects from any script execution attacks by blocking them
at time of the feed registration.
Opera: Scenarios (1) and (2)
Re: 3rd party patch for XP for MS09-048?
Is this relevant? QUOTE--- Protect to 2 for the best protection against SYN attacks. This value adds additional delays to connection indications, and TCP connection requests quickly timeout when a SYN attack is in progress. This parameter is the recommended setting. NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows - IIRC? This is called the "Silly Window Syndrome", & this is a way, in theory, around it... & iirc, "Scalable Windows", via setsockopt API calls from an attacker are what the problem is here anyhow & this ought to 'stall it'... thoughts/feedback? APK P.S.=> Also, "hardcoding" the TcpWindowSize & GlobalTcpWindowSize settings in the registry in TCP/IP Parameters (see registry path above) SHOULD also help here also, for servers that can accept MANY connections from MANY clients, worldwide, as your specific constraints specify... Thus, effectively stalling the ability to use TcpWindowScaling is stopped by SynAttackProtect too, so an attacking system/app sending a setsockopt of 0 for this SHOULD also be nullified, on a server also... (However/Again - Workstations are easily taken care of , vs. servers, just by what I wrote up above either by PORT FILTERING) IP Security Policies, which can work on ranges of addresses to block, OR, single systems as well you either ALLOW or DENY to talk to your system, still can help also... vs. a DDOS though? SynAttackProtect is your best friend here... you'd use netstat -b -n tcp to see which are held in a 1/2 open SYN-RECEIVE state, & BLOCK THOSE FROM SENDING YOUR WAY (or just by doing it in a router or routing table)... takers anyone, on these thoughts (especially for Windows 2000)? Thanks for your time... apk UNQUOTE-- Source: http://tech.slashdot.org/comments.pl?sid=1368439&cid=29424787 Susan Bradley wrote: It's not that they aren't supported per se, just that Microsoft has deemed the impact of DOS to be low, the ability to patch that platform impossible/difficult and thus have make a risk calculation accordingly. Sometimes the architecture is what it is. Jeffrey Walton wrote: Hi Susan, Read the bulletin. There's no patch. It is deemed by Microsoft to be of low impact and thus no patch has been built. I don't know how I missed that XP/SP2 and above were not being patched. It appears that my two references are worhtless... I used to use them in position papers! * http://support.microsoft.com/gp/lifepolicy * http://support.microsoft.com/gp/lifeselect Jeff On Tue, Sep 15, 2009 at 5:24 PM, Susan Bradley wrote: Read the bulletin. There's no patch. It is deemed by Microsoft to be of low impact and thus no patch has been built. Jeffrey Walton wrote: Hi Aras, Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, Can you cite a reference? Unless Microsoft has changed their end of life policy [1], XP should be patched for security vulnerabilities until about 2014. Both XP Home and XP Pro's mainstream support ended in 4/2009, but extended support ends in 4/2014 [2]. Given that we know the end of extended support, take a look at bullet 17 of [1]: 17. What is the Security Update policy? Security updates will be available through the end of the Extended Support phase (five years of Mainstream Support plus five years of the Extended Support) at no additional cost for most products. Security updates will be posted on the Microsoft Update Web site during both the Mainstream and the Extended Support phase. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... Not at all. Jeff [1] http://support.microsoft.com/gp/lifepolicy [2] http://support.microsoft.com/gp/lifeselect On Tue, Sep 15, 2009 at 2:46 PM, Aras "Russ" Memisyazici wrote: Hello All: Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, I'm now curious to find out whether or not any brave souls out there are already working or willing to work on an open-source patch to remediate the issue within XP. I realize some of you might be tempted to relay the M$ BS about "not being feasible because it's a lot of work" rhetoric... I would just like to hear the thoughts of the true experts subscribed to these lists :) No harm in that is there? Aras "Russ" Memisyazici Systems Administrator Virginia Tech
Re: 3rd party patch for XP for MS09-048?
Only if you are a consumer. In a network we ALL have listening ports out there. elizabeth.a.gre...@gmail.com wrote: As I understand the bulletin, Microsoft will not be releasing MS09-048 patches for XP because, by default, it runs no listening services or the windows firewall can protect it. Quoting http://www.microsoft.com/technet/security/bulletin/MS09-048.mspx "If Windows XP is listed as an affected product, why is Microsoft not issuing an update for it? By default, Windows XP Service Pack 2, Windows XP Service Pack 3, and Windows XP Professional x64 Edition Service Pack 2 do not have a listening service configured in the client firewall and are therefore not affected by this vulnerability. Windows XP Service Pack 2 and later operating systems include a stateful host firewall that provides protection for computers against incoming traffic from the Internet or from neighboring network devices on a private network. ... Customers running Windows XP are at reduced risk, and Microsoft recommends they use the firewall included with the operating system, or a network firewall, to block access to the affected ports and limit the attack surface from untrusted networks." -eg
RE: [Full-disclosure] 3rd party patch for XP for MS09-048?
Hey Larry- hope everything's going well... When you've got a systemic vulnerability, in this case the TCP/IP stack itself, exploitation information must be explicit and definitive. I'm fine with risk classification, and I appreciate efforts to categorize risk into manageable exposure metrics, but we shouldn't have to infer potential vulnerability information from vague disclosure data. I know many response teams base patch paths on the published severity, but one also has to be able to make decisions on their own. For me, no big deal. But it's not that simple for others. But there's not enough information for me to make that call. Is it for ANY "listening service?" TCP or UPD? Does the "statefull" firewall introduced in subsequent versions stop it? The answers are "yes," "yes," and "no." They should just say that. Is it "low" because the firewall doesn't have any exceptions by default? If so, that's silly. Everyone using XP for anything has incoming connections for something, and well known if on a domain. I feel sorry for Diebold and NEC with all the ATMs out there running XP, but fortunately, I'm not responsible for clients using their systems anymore :) Anyway, the DoS suxx0rz, but I'm more irritated with the lack of real, straight-forward, no-nonsense information and technical sleight of hand. The information should be painfully obvious, not obviously painful. t > -Original Message- > From: Larry Seltzer [mailto:la...@larryseltzer.com] > Sent: Wednesday, September 16, 2009 8:21 AM > To: Thor (Hammer of God); Eric C. Lukens; bugtraq@securityfocus.com > Cc: full-disclos...@lists.grok.org.uk > Subject: RE: [Full-disclosure] 3rd party patch for XP for MS09-048? > > I agree that the FAQ explanation in the advisory is vague about what > protection the firewall provides. One clue I would infer about it is > that they rated this a "Low" threat. If it were vulnerable in the > default configuration, with the firewall (or some other firewall) on, > they probably would have rated it at least Medium. If I'm wrong about > that then the "Low" rating is misleading. > > Larry Seltzer > Contributing Editor, PC Magazine > larry_selt...@ziffdavis.com > http://blogs.pcmag.com/securitywatch/ > > > -Original Message- > From: full-disclosure-boun...@lists.grok.org.uk > [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Thor > (Hammer of God) > Sent: Wednesday, September 16, 2009 11:00 AM > To: Eric C. Lukens; bugtraq@securityfocus.com > Cc: full-disclos...@lists.grok.org.uk > Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? > > Thanks for the link. The problem here is that not enough information > is > given, and what IS given is obviously watered down to the point of > being > ineffective. > > The quote that stands out most for me: > > During the Q&A, however, Windows users repeatedly asked Microsoft's > security team to explain why it wasn't patching XP, or if, in certain > scenarios, their machines might be at risk. "We still use Windows XP > and > we do not use Windows Firewall," read one of the user questions. "We > use > a third-party vendor firewall product. Even assuming that we use the > Windows Firewall, if there are services listening, such as remote > desktop, wouldn't then Windows XP be vulnerable to this?" > > "Servers are a more likely target for this attack, and your firewall > should provide additional protections against external exploits," > replied Stone and Bryant. > > > If an employee managing a product that my company owned gave answers > like that to a public interview with Computerworld, they would be in > deep doo. First off, my default install of XP Pro SP2 has remote > assistance inbound, and once you join to a domain, you obviously accept > necessary domain traffic. This "no inbound traffic by default so you > are not vulnerable" line is crap. It was a direct question - "If RDP > is > allowed through the firewall, are we vulnerable?" A:"Great question. > Yes, servers are the target. A firewall should provide added > protection, maybe. Rumor is that's what they are for. Not sure > really. > What was the question again?" > > You don't get "trustworthy" by not answering people's questions, > particularly when they are good, obvious questions. Just be honest > about it. "Yes, XP is vulnerable to a DOS. Your firewall might help, > but don't bet on it. XP code is something like 15 years old now, and > we're not going to change it. That's the way it is, sorry. Just be > glad > you're using XP and not 2008/vista or you'd be patching your arse off > right now." > > If MSFT thinks they are mitigating public opinion issues by > side-stepping questions and not fully exposing the problems, they are > wrong. This just makes it worse. That's the long answer. The short > answer is "XP is vulnerable to a DoS, and a patch is not being > offered." > > t > > > > > -Original Message- > > Fro
Iret #GP on pre-commit handling failure: the NetBSD case (CVE-2009-2793)
Iret #GP on pre-commit handling failure: the NetBSD case (CVE-2009-2793)
On the Intel architecture, once an operating system kernel has completed
servicing an interrupt or exception, it will generally return to user
mode using iret. The iret instruction will restore the context required
to continue execution, such as code segment, instruction pointer, flags
and so on.
iret is a complex instruction whose pseudocode alone spans several pages
of the software developers manual. Interestingly, in protected mode it
is executed in two distinct stages, a pre-commit stage (before privilege
level is changed) and a post-commit stage (after privilege level is
changed). You can see the commit point in the pseudocode below (taken
from Intel manual, comment is ours)
IF new mode != 64-Bit Mode
THEN
IF tempEIP is not within code segment limits
THEN #GP(0); FI;
EIP <- tempEIP;
ELSE (* new mode = 64-bit mode *)
IF tempRIP is non-canonical
THEN #GP(0); FI;
RIP <- tempRIP;
FI;
CS <- tempCS; // This is the commit point (privilege switch)
EFLAGS (CF, PF, AF, ZF, SF, TF, DF, OF, NT) <- tempEFLAGS;
When the processor handles an exception, two cases can arise:
- the handler procedure is executed at the same level of privilege
as the interrupted procedure, no stack switch occurs
- the handler procedure is executed at a different privilege level,
therefore a stack switch occurs
The generated stack frame will be different if a stack switch occurs,
because the processor needs to save the interrupted procedure's stack.
When iret returns to a different privilege level, its behaviour on
failure will depend on which stage of the operation it is currently
executing. A pre-commit failure will induce no stack-switching while a
post-commit failure will induce a stack switching and therefore generate
a different size trap frame.
Affected Software
It's easy to overlook this distinction and we have found multiple cases
where this has had direct security consequences or made other issues
exploitable.
For instance, the NetBSD kernel on x86 does not handle pre-commit failures
properly.
We can easily make iret fail pre-commit by having tempEIP outside the
code segment limits.
- The canonical way to do this is to set-up a LDT entry with a code segment
limited to 0x1FFF. mmap memory at 0x1000 and then put some shellcode with
an int 0x80 at the very end of this page, so that when the kernel iret,
tempEIP is past the code segment limits.
- Interestingly, because of the lazy handling of non executable stack
emulation on x86, this bug could be triggered by a non malicious
program:
/* ... */
int main(int argc, char **argv)
{
jmp_buf env;
void handlesig(int n) {
longjmp(env, 1);
}
signal(SIGSEGV, handlesig);
if (setjmp(env) == 0) {
( (void(*)(void)) NULL) ();
}
return 0;
}
/* ... */
int main(int argc, char **argv)
{
char baguette;
signal(SIGABRT, (void (*)(int))&baguette);
abort();
}
Consequences
---
In the NetBSD case, the kernel stack will get desynchronized. This might
allow an attacker to elevate privileges.
---
Solution
---
We reported this to NetBSD developpers in May. Obviously, the fix is
non trivial, and after much discussion, we agreed to release this
information to open this issue to the wider NetBSD developement
community.
---
Credit
---
This bug was discovered by Tavis Ormandy and Julien Tinnes of the Google
Security Team.
Re: [Full-disclosure] 3rd party patch for XP for MS09-048?
It's only "default" for people running XP standalone/consumer that are not even in a home network settings. That kinda slices and dices that default down to a VERY narrow sub sub sub set of customer base. (Bottom line, yes, the marketing team definitely got a hold of that bulletin) Thor (Hammer of God) wrote: Yeah, I know what it is and what it's for ;) That was just my subtle way of trying to make a point. To be more explicit: 1) If you are publishing a vulnerability for which there is no patch, and for which you have no intention of making a patch for, don't tell me it's mitigated by ancient, unusable default firewall settings, and don't withhold explicit details. Say "THERE WILL BE NO PATCH, EVER. HERE'S EVERYTHING WE KNOW SO YOU CAN DETERMINE YOUR OWN RISK." Also, don't say 'you can deploy firewall settings via group policy to mitigate exposure' when the firewall obviously must be accepting network connections to get the settings in the first place. If all it takes is any listening service, then you have issues. It's like telling me that "the solution is to take the letter 'f' out of the word "solution." 2) Think things through. If you are going to try to boot sales of Win7 to corporate customers by providing free XP VM technology and thus play up how important XP is and how many companies still depend upon it for business critical application compatibility, don't deploy that technology in an other-than-default configuration that is subject to a DoS exploit while downplaying the extent that the exploit may be leveraged by saying that a "typical" default configuration mitigates it while choosing not to ever patch it.Seems like simple logic points to me. t -Original Message- From: Susan Bradley [mailto:sbrad...@pacbell.net] Sent: Wednesday, September 16, 2009 10:16 AM To: Thor (Hammer of God) Cc: bugtraq@securityfocus.com; full-disclos...@lists.grok.org.uk Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? It's XP. Running in RDP mode. It's got IE6, and wants antivirus. Of course it's vulnerable to any and all gobs of stuff out there. But it's goal and intent is to allow Small shops to deploy Win7. If you need more security, get appv/medv/whateverv or other virtualization. It's not a security platform. It's a get the stupid 16 bit line of business app working platform. Thor (Hammer of God) wrote: P.S. Anyone check to see if the default "XP Mode" VM you get for free with Win7 hyperv is vulnerable and what the implications are for a host running an XP vm that get's DoS'd are? I get the whole "XP code to too old to care" bit, but it seems odd to take that "old code" and re-market it around compatibility and re- distribute it with free downloads for Win7 while saying "we won't patch old code." t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- disclosure-boun...@lists.grok.org.uk] On Behalf Of Thor (Hammer of God) Sent: Wednesday, September 16, 2009 8:00 AM To: Eric C. Lukens; bugtraq@securityfocus.com Cc: full-disclos...@lists.grok.org.uk Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? Thanks for the link. The problem here is that not enough information is given, and what IS given is obviously watered down to the point of being ineffective. The quote that stands out most for me: During the Q&A, however, Windows users repeatedly asked Microsoft's security team to explain why it wasn't patching XP, or if, in certain scenarios, their machines might be at risk. "We still use Windows XP and we do not use Windows Firewall," read one of the user questions. "We use a third-party vendor firewall product. Even assuming that we use the Windows Firewall, if there are services listening, such as remote desktop, wouldn't then Windows XP be vulnerable to this?" "Servers are a more likely target for this attack, and your firewall should provide additional protections against external exploits," replied Stone and Bryant. If an employee managing a product that my company owned gave answers like that to a public interview with Computerworld, they would be in deep doo. First off, my default install of XP Pro SP2 has remote assistance inbound, and once you join to a domain, you obviously accept necessary domain traffic. This "no inbound traffic by default so you are not vulnerable" line is crap. It was a direct question - "If RDP is allowed through the firewall, are we vulnerable?" A:"Great question. Yes, servers are the target. A firewall should provide added protection, maybe. Rumor is that's what they are for. Not sure really. What was the question again?" You don't get "trustworthy" by not answering people's questions, particularly when they are good, obvious questions. Just be honest about it. "Yes,
RE: [Full-disclosure] 3rd party patch for XP for MS09-048?
Yeah, I know what it is and what it's for ;) That was just my subtle way of trying to make a point. To be more explicit: 1) If you are publishing a vulnerability for which there is no patch, and for which you have no intention of making a patch for, don't tell me it's mitigated by ancient, unusable default firewall settings, and don't withhold explicit details. Say "THERE WILL BE NO PATCH, EVER. HERE'S EVERYTHING WE KNOW SO YOU CAN DETERMINE YOUR OWN RISK." Also, don't say 'you can deploy firewall settings via group policy to mitigate exposure' when the firewall obviously must be accepting network connections to get the settings in the first place. If all it takes is any listening service, then you have issues. It's like telling me that "the solution is to take the letter 'f' out of the word "solution." 2) Think things through. If you are going to try to boot sales of Win7 to corporate customers by providing free XP VM technology and thus play up how important XP is and how many companies still depend upon it for business critical application compatibility, don't deploy that technology in an other-than-default configuration that is subject to a DoS exploit while downplaying the extent that the exploit may be leveraged by saying that a "typical" default configuration mitigates it while choosing not to ever patch it.Seems like simple logic points to me. t > -Original Message- > From: Susan Bradley [mailto:sbrad...@pacbell.net] > Sent: Wednesday, September 16, 2009 10:16 AM > To: Thor (Hammer of God) > Cc: bugtraq@securityfocus.com; full-disclos...@lists.grok.org.uk > Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? > > It's XP. Running in RDP mode. It's got IE6, and wants antivirus. Of > course it's vulnerable to any and all gobs of stuff out there. But > it's > goal and intent is to allow Small shops to deploy Win7. If you need > more security, get appv/medv/whateverv or other virtualization. > > It's not a security platform. It's a get the stupid 16 bit line of > business app working platform. > > Thor (Hammer of God) wrote: > > P.S. > > > > Anyone check to see if the default "XP Mode" VM you get for free with > Win7 hyperv is vulnerable and what the implications are for a host > running an XP vm that get's DoS'd are? > > > > I get the whole "XP code to too old to care" bit, but it seems odd to > take that "old code" and re-market it around compatibility and re- > distribute it with free downloads for Win7 while saying "we won't patch > old code." > > > > t > > > > > >> -Original Message- > >> From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- > >> disclosure-boun...@lists.grok.org.uk] On Behalf Of Thor (Hammer of > God) > >> Sent: Wednesday, September 16, 2009 8:00 AM > >> To: Eric C. Lukens; bugtraq@securityfocus.com > >> Cc: full-disclos...@lists.grok.org.uk > >> Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? > >> > >> Thanks for the link. The problem here is that not enough > information > >> is given, and what IS given is obviously watered down to the point > of > >> being ineffective. > >> > >> The quote that stands out most for me: > >> > >> During the Q&A, however, Windows users repeatedly asked Microsoft's > >> security team to explain why it wasn't patching XP, or if, in > certain > >> scenarios, their machines might be at risk. "We still use Windows XP > >> and we do not use Windows Firewall," read one of the user questions. > >> "We use a third-party vendor firewall product. Even assuming that we > >> use the Windows Firewall, if there are services listening, such as > >> remote desktop, wouldn't then Windows XP be vulnerable to this?" > >> > >> "Servers are a more likely target for this attack, and your firewall > >> should provide additional protections against external exploits," > >> replied Stone and Bryant. > >> > >> > >> If an employee managing a product that my company owned gave answers > >> like that to a public interview with Computerworld, they would be in > >> deep doo. First off, my default install of XP Pro SP2 has remote > >> assistance inbound, and once you join to a domain, you obviously > accept > >> necessary domain traffic. This "no inbound traffic by default so > you > >> are not vulnerable" line is crap. It was a direct question - "If > RDP > >> is allowed through the firewall, are we vulnerable?" A:"Great > question. > >> Yes, servers are the target. A firewall should provide added > >> protection, maybe. Rumor is that's what they are for. Not sure > >> really. What was the question again?" > >> > >> You don't get "trustworthy" by not answering people's questions, > >> particularly when they are good, obvious questions. Just be honest > >> about it. "Yes, XP is vulnerable to a DOS. Your firewall might > help, > >> but don't bet on it. XP code is something like 15 years old now, > and > >> we're not going to change it. That's the way it is, sorry. J
Re: [Full-disclosure] 3rd party patch for XP for MS09-048?
It's XP. Running in RDP mode. It's got IE6, and wants antivirus. Of course it's vulnerable to any and all gobs of stuff out there. But it's goal and intent is to allow Small shops to deploy Win7. If you need more security, get appv/medv/whateverv or other virtualization. It's not a security platform. It's a get the stupid 16 bit line of business app working platform. Thor (Hammer of God) wrote: P.S. Anyone check to see if the default "XP Mode" VM you get for free with Win7 hyperv is vulnerable and what the implications are for a host running an XP vm that get's DoS'd are? I get the whole "XP code to too old to care" bit, but it seems odd to take that "old code" and re-market it around compatibility and re-distribute it with free downloads for Win7 while saying "we won't patch old code." t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- disclosure-boun...@lists.grok.org.uk] On Behalf Of Thor (Hammer of God) Sent: Wednesday, September 16, 2009 8:00 AM To: Eric C. Lukens; bugtraq@securityfocus.com Cc: full-disclos...@lists.grok.org.uk Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? Thanks for the link. The problem here is that not enough information is given, and what IS given is obviously watered down to the point of being ineffective. The quote that stands out most for me: During the Q&A, however, Windows users repeatedly asked Microsoft's security team to explain why it wasn't patching XP, or if, in certain scenarios, their machines might be at risk. "We still use Windows XP and we do not use Windows Firewall," read one of the user questions. "We use a third-party vendor firewall product. Even assuming that we use the Windows Firewall, if there are services listening, such as remote desktop, wouldn't then Windows XP be vulnerable to this?" "Servers are a more likely target for this attack, and your firewall should provide additional protections against external exploits," replied Stone and Bryant. If an employee managing a product that my company owned gave answers like that to a public interview with Computerworld, they would be in deep doo. First off, my default install of XP Pro SP2 has remote assistance inbound, and once you join to a domain, you obviously accept necessary domain traffic. This "no inbound traffic by default so you are not vulnerable" line is crap. It was a direct question - "If RDP is allowed through the firewall, are we vulnerable?" A:"Great question. Yes, servers are the target. A firewall should provide added protection, maybe. Rumor is that's what they are for. Not sure really. What was the question again?" You don't get "trustworthy" by not answering people's questions, particularly when they are good, obvious questions. Just be honest about it. "Yes, XP is vulnerable to a DOS. Your firewall might help, but don't bet on it. XP code is something like 15 years old now, and we're not going to change it. That's the way it is, sorry. Just be glad you're using XP and not 2008/vista or you'd be patching your arse off right now." If MSFT thinks they are mitigating public opinion issues by side- stepping questions and not fully exposing the problems, they are wrong. This just makes it worse. That's the long answer. The short answer is "XP is vulnerable to a DoS, and a patch is not being offered." t -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- disclosure-boun...@lists.grok.org.uk] On Behalf Of Eric C. Lukens Sent: Tuesday, September 15, 2009 2:37 PM To: bugtraq@securityfocus.com Cc: full-disclos...@lists.grok.org.uk Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? Reference: http://www.computerworld.com/s/article/9138007/Microsoft_No_TCP_IP_patc hes_for_you_XP MS claims the patch would require to much overhaul of XP to make it worth it, and they may be right. Who knows how many applications might break that were designed for XP if they have to radically change the TCP/IP stack. Now, I don't know if the MS speak is true, but it certainly sounds like it is not going to be patched. The other side of the MS claim is that a properly-firewalled XP system would not be vulnerable to a DOS anyway, so a patch shouldn't be necessary. -Eric Original Message Subject: Re: 3rd party patch for XP for MS09-048? From: Jeffrey Walton To: nowh...@devnull.com Cc: bugtraq@securityfocus.com, full-disclos...@lists.grok.org.uk Date: 9/15/09 3:49 PM Hi Aras, Given that M$ has officially shot-down all current Windows XP users by not issuing a patch for a DoS level issue, Can you cite a reference? Unless Microsoft has changed their end of life policy [1], XP should be patched for security vulnerabilities until about 2014. Both XP Home and XP Pro's mainstream support ended in
[SECURITY] [DSA 1889-1] New icu packages correct multibyte sequence parsing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1889-1 secur...@debian.org http://www.debian.org/security/ Moritz Muehlenhoff September 16, 2009http://www.debian.org/security/faq - Package: icu Vulnerability : programming error Problem type : local(remote) Debian-specific: no CVE Id(s) : CVE-2009-0153 It was discovered that the ICU unicode library performed incorrect processing of invalid multibyte sequences, resulting in potential bypass of security mechanisms. For the old stable distribution (etch), this problem has been fixed in version 3.6-2etch3. For the stable distribution (lenny), this problem has been fixed in version 3.8.1-3+lenny2. For the unstable distribution (sid), this problem has been fixed in version 4.0.1-1. We recommend that you upgrade your icu packages. Upgrade instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 4.0 alias etch - --- Oldstable updates are available for alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/i/icu/icu_3.6-2etch3.dsc Size/MD5 checksum: 592 8b600075600533ce08c9801ffa571a19 http://security.debian.org/pool/updates/main/i/icu/icu_3.6-2etch3.diff.gz Size/MD5 checksum:45190 601af38fe10a27e08e40985c409bc6c4 http://security.debian.org/pool/updates/main/i/icu/icu_3.6.orig.tar.gz Size/MD5 checksum: 9778863 0f1bda1992b4adca62da68a7ad79d830 Architecture independent packages: http://security.debian.org/pool/updates/main/i/icu/icu-doc_3.6-2etch3_all.deb Size/MD5 checksum: 3239572 8bf16fb7db375fb14de7082bcb814733 alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/i/icu/libicu36_3.6-2etch3_alpha.deb Size/MD5 checksum: 5586140 1244a1b89188c020a97468dc25d22af7 http://security.debian.org/pool/updates/main/i/icu/libicu36-dev_3.6-2etch3_alpha.deb Size/MD5 checksum: 7012868 8680617bb8c38f6abef169b572a76baa amd64 architecture (AMD x86_64 (AMD64)) http://security.debian.org/pool/updates/main/i/icu/libicu36_3.6-2etch3_amd64.deb Size/MD5 checksum: 5444866 f9271ec21977880f74955cfe06b7580d http://security.debian.org/pool/updates/main/i/icu/libicu36-dev_3.6-2etch3_amd64.deb Size/MD5 checksum: 6573726 25374ce8e6ae12b655a9744db65b9455 hppa architecture (HP PA RISC) http://security.debian.org/pool/updates/main/i/icu/libicu36_3.6-2etch3_hppa.deb Size/MD5 checksum: 5913798 20c8976b23d28d9bc91ea053748d79e0 http://security.debian.org/pool/updates/main/i/icu/libicu36-dev_3.6-2etch3_hppa.deb Size/MD5 checksum: 7110674 bee82145df32672bf5d61e29dd3d6bc3 i386 architecture (Intel ia32) http://security.debian.org/pool/updates/main/i/icu/libicu36-dev_3.6-2etch3_i386.deb Size/MD5 checksum: 6466444 d8e1c31e6f1d238353340a9b82da1ed8 http://security.debian.org/pool/updates/main/i/icu/libicu36_3.6-2etch3_i386.deb Size/MD5 checksum: 5470148 f5d9e50ecb224df9ae4f0c7057097f54 ia64 architecture (Intel ia64) http://security.debian.org/pool/updates/main/i/icu/libicu36_3.6-2etch3_ia64.deb Size/MD5 checksum: 5869036 c305e7cff86ad5584c4842fec7619fd8 http://security.debian.org/pool/updates/main/i/icu/libicu36-dev_3.6-2etch3_ia64.deb Size/MD5 checksum: 7243932 effc8dc2ed962de903e848ff402c167a mips architecture (MIPS (Big Endian)) http://security.debian.org/pool/updates/main/i/icu/libicu36_3.6-2etch3_mips.deb Size/MD5 checksum: 5747354 39624db186bbf7ce259c47681d0a1cfc http://security.debian.org/pool/updates/main/i/icu/libicu36-dev_3.6-2etch3_mips.deb Size/MD5 checksum: 7052540 c159699731d592ec60fcfd4bbe010a51 mipsel architecture (MIPS (Little Endian)) http://security.debian.org/pool/updates/main/i/icu/libicu36-dev_3.6-2etch3_mipsel.deb Size/MD5 checksum: 6769230 32e24d0b40b3f2e62e0c2c4c4be96dce http://security.debian.org/pool/updates/main/i/icu/libicu36_3.6-2etch3_mipsel.deb Size/MD5 checksum: 5464426 5f544b29dd41d8326ddfd70b31e4045a powerpc architecture (PowerPC) http://security.debian.org/pool/updates/main/i/icu/libicu36-dev_3.6-2etch3_powerpc.deb Size/MD5 checksum: 6891510 af8e8b416b43a9d6c5f5893dd63261d6 http://security.debian.org/pool/updates/main/i/icu/libicu36_3.6-2etch3_powerpc.deb Size/MD5 checksum: 5750422 ec7b53398b703da8f7e166a337
[USN-832-1] FreeRADIUS vulnerability
=== Ubuntu Security Notice USN-832-1 September 16, 2009 freeradius vulnerability CVE-2009-3111 === A security issue affects the following Ubuntu releases: Ubuntu 8.04 LTS This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 8.04 LTS: freeradius 1.1.7-1ubuntu0.2 In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: It was discovered that FreeRADIUS did not correctly handle certain malformed attributes. A remote attacker could exploit this flaw and cause the FreeRADIUS server to crash, resulting in a denial of service. Updated packages for Ubuntu 8.04 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius_1.1.7-1ubuntu0.2.diff.gz Size/MD5:29420 24046205ce4000d6936fffda082f1c56 http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius_1.1.7-1ubuntu0.2.dsc Size/MD5: 1089 f48ac81f667771d7867602f012de0ae1 http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius_1.1.7.orig.tar.gz Size/MD5: 2673548 4bbdb04b5778b0703e62edb51fdf3e01 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-dialupadmin_1.1.7-1ubuntu0.2_all.deb Size/MD5: 116132 0c597d55be61f8eb86218545a97a1909 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-dbg_1.1.7-1ubuntu0.2_amd64.deb Size/MD5: 655586 a5d8de1ce68ec51a637e5fbcb803db6c http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-iodbc_1.1.7-1ubuntu0.2_amd64.deb Size/MD5:35026 d3518140284d52145cd4b7af58061dba http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-krb5_1.1.7-1ubuntu0.2_amd64.deb Size/MD5:35526 269e282963da95f8bf0fb6ebd13ebe59 http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-ldap_1.1.7-1ubuntu0.2_amd64.deb Size/MD5:52338 2e7a50a19cb73bacdb6ce2980aaeeef8 http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-mysql_1.1.7-1ubuntu0.2_amd64.deb Size/MD5:35310 9934a770a60b6e0bb27884b13ad65fad http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-postgresql_1.1.7-1ubuntu0.2_amd64.deb Size/MD5:35398 dc0c40b8264b720a6a7a0ff2e84ecdc1 http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius_1.1.7-1ubuntu0.2_amd64.deb Size/MD5: 797758 d64c394fe55cd69b6ac5d72143f75187 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-dbg_1.1.7-1ubuntu0.2_i386.deb Size/MD5: 606818 a6c2dc55d5ba7608abb6eed82acfcc1e http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-iodbc_1.1.7-1ubuntu0.2_i386.deb Size/MD5:34594 b9cbc077759d123b38f40b5fcc591ac6 http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-krb5_1.1.7-1ubuntu0.2_i386.deb Size/MD5:35276 7e3fb463c80e7fbaa8ef8b80e008ef30 http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-ldap_1.1.7-1ubuntu0.2_i386.deb Size/MD5:51824 80688022b2a0b66420dd8455844e369c http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-mysql_1.1.7-1ubuntu0.2_i386.deb Size/MD5:34838 b9da2e5a7b74b24d5914c8e55c258a7d http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius-postgresql_1.1.7-1ubuntu0.2_i386.deb Size/MD5:34956 8dbb9423504cc0f6d3c0fd7ded42819d http://security.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius_1.1.7-1ubuntu0.2_i386.deb Size/MD5: 768668 c6c7869016c18ab096c5a6c303ee4639 lpia architecture (Low Power Intel Architecture): http://ports.ubuntu.com/pool/main/f/freeradius/freeradius-dbg_1.1.7-1ubuntu0.2_lpia.deb Size/MD5: 616284 5c6e1f2aa8c06c4caa8d5ca35661c317 http://ports.ubuntu.com/pool/main/f/freeradius/freeradius-iodbc_1.1.7-1ubuntu0.2_lpia.deb Size/MD5:34430 b8621d65be2cefe3860ec5075f4c0807 http://ports.ubuntu.com/pool/main/f/freeradius/freeradius-krb5_1.1.7-1ubuntu0.2_lpia.deb Size/MD5:35238 13f31fff6a5e77e9784c3396eea9a811 http://ports.ubuntu.com/pool/main/f/freeradius/freeradius-ldap_1.1.7-1ubuntu0.2_lpia.deb Size/MD5:51932 ab7fd210c158808b29d7bf253d79ba63 http://ports.ubuntu.com/pool/main/f/freeradius/freeradius-mysql_1.1.7-1ubuntu0.2_lpia.deb Size/MD5:34750 078e6c6e37906da714259410bf22d005 http://ports.ubuntu.com/pool/main/f/freeradius/freeradius-postgresql_1.1.7-1ubuntu0.2_lpia.deb Size/MD5:34964 2b3eb937c8e0fbe4bd38ebcdf5de597f http://ports.ubuntu.com/pool/main/f/freeradius/freerad
Re: 3rd party patch for XP for MS09-048?
Susan Bradley wrote: > Only if you are a consumer. In a network we ALL have listening ports > out there. This is simply Microsofts way of forcing you to upgrade your OS. They pulled the same shenanigans with Windows 2000, if you do not recall. I'd have to say, it's time to re-evaluate where you are funneling your $$$. If the vendor that you PAID your hard earned dollars to is not supporting their product like they said they would, then it's time to move on. There are plenty of alternatives out there. No one says you _have_ to run Windows. > > elizabeth.a.gre...@gmail.com wrote: >> As I understand the bulletin, Microsoft will not be releasing MS09-048 >> patches for XP because, by default, it runs no listening services or >> the windows firewall can protect it. >> >> Quoting http://www.microsoft.com/technet/security/bulletin/MS09-048.mspx >> "If Windows XP is listed as an affected product, why is Microsoft not >> issuing an update for it? >> By default, Windows XP Service Pack 2, Windows XP Service Pack 3, and >> Windows XP Professional x64 Edition Service Pack 2 do not have a >> listening service configured in the client firewall and are therefore >> not affected by this vulnerability. Windows XP Service Pack 2 and >> later operating systems include a stateful host firewall that provides >> protection for computers against incoming traffic from the Internet or >> from neighboring network devices on a private network. ... Customers >> running Windows XP are at reduced risk, and Microsoft recommends they >> use the firewall included with the operating system, or a network >> firewall, to block access to the affected ports and limit the attack >> surface from untrusted networks." >> >> -eg >> >> > > -- Rob +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | _ | | ASCII ribbon campaign ( ) | | - against HTML email X | |/ \ | | | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Re: 3rd party patch for XP for MS09-048?
Cloud option maybe as we go forward but right now today, this is business making the decisions here. Desktop, if it were that easy we'd have ripped out desktops years ago. Businesses have to be realistic. Sometimes there is not "plenty of comparable alternatives out there". Sometimes the boss/business needs/line of business apps dictates you run windows. Rob Thompson wrote: Susan Bradley wrote: Only if you are a consumer. In a network we ALL have listening ports out there. This is simply Microsofts way of forcing you to upgrade your OS. They pulled the same shenanigans with Windows 2000, if you do not recall. I'd have to say, it's time to re-evaluate where you are funneling your $$$. If the vendor that you PAID your hard earned dollars to is not supporting their product like they said they would, then it's time to move on. There are plenty of alternatives out there. No one says you _have_ to run Windows. elizabeth.a.gre...@gmail.com wrote: As I understand the bulletin, Microsoft will not be releasing MS09-048 patches for XP because, by default, it runs no listening services or the windows firewall can protect it. Quoting http://www.microsoft.com/technet/security/bulletin/MS09-048.mspx "If Windows XP is listed as an affected product, why is Microsoft not issuing an update for it? By default, Windows XP Service Pack 2, Windows XP Service Pack 3, and Windows XP Professional x64 Edition Service Pack 2 do not have a listening service configured in the client firewall and are therefore not affected by this vulnerability. Windows XP Service Pack 2 and later operating systems include a stateful host firewall that provides protection for computers against incoming traffic from the Internet or from neighboring network devices on a private network. ... Customers running Windows XP are at reduced risk, and Microsoft recommends they use the firewall included with the operating system, or a network firewall, to block access to the affected ports and limit the attack surface from untrusted networks." -eg
RE: [Full-disclosure] 3rd party patch for XP for MS09-048?
Yes, they used the bulletin to soft-pedal the description, but at the same time I think they send a message about XP users being on shaky ground. Just because they've got 4+ years of Extended Support Period left doesn't mean they're going to get first-class treatment. Larry Seltzer Contributing Editor, PC Magazine larry_selt...@ziffdavis.com http://blogs.pcmag.com/securitywatch/ -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Susan Bradley Sent: Wednesday, September 16, 2009 2:26 PM To: Thor (Hammer of God) Cc: full-disclos...@lists.grok.org.uk; bugtraq@securityfocus.com Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? It's only "default" for people running XP standalone/consumer that are not even in a home network settings. That kinda slices and dices that default down to a VERY narrow sub sub sub set of customer base. (Bottom line, yes, the marketing team definitely got a hold of that bulletin) Thor (Hammer of God) wrote: > Yeah, I know what it is and what it's for ;) That was just my subtle way of trying to make a point. To be more explicit: > > 1) If you are publishing a vulnerability for which there is no patch, and for which you have no intention of making a patch for, don't tell me it's mitigated by ancient, unusable default firewall settings, and don't withhold explicit details. Say "THERE WILL BE NO PATCH, EVER. HERE'S EVERYTHING WE KNOW SO YOU CAN DETERMINE YOUR OWN RISK." Also, don't say 'you can deploy firewall settings via group policy to mitigate exposure' when the firewall obviously must be accepting network connections to get the settings in the first place. If all it takes is any listening service, then you have issues. It's like telling me that "the solution is to take the letter 'f' out of the word "solution." > > 2) Think things through. If you are going to try to boot sales of Win7 to corporate customers by providing free XP VM technology and thus play up how important XP is and how many companies still depend upon it for business critical application compatibility, don't deploy that technology in an other-than-default configuration that is subject to a DoS exploit while downplaying the extent that the exploit may be leveraged by saying that a "typical" default configuration mitigates it while choosing not to ever patch it.Seems like simple logic points to me. > > t > > >> -Original Message- >> From: Susan Bradley [mailto:sbrad...@pacbell.net] >> Sent: Wednesday, September 16, 2009 10:16 AM >> To: Thor (Hammer of God) >> Cc: bugtraq@securityfocus.com; full-disclos...@lists.grok.org.uk >> Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? >> >> It's XP. Running in RDP mode. It's got IE6, and wants antivirus. Of >> course it's vulnerable to any and all gobs of stuff out there. But >> it's >> goal and intent is to allow Small shops to deploy Win7. If you need >> more security, get appv/medv/whateverv or other virtualization. >> >> It's not a security platform. It's a get the stupid 16 bit line of >> business app working platform. >> >> Thor (Hammer of God) wrote: >> >>> P.S. >>> >>> Anyone check to see if the default "XP Mode" VM you get for free with >>> >> Win7 hyperv is vulnerable and what the implications are for a host >> running an XP vm that get's DoS'd are? >> >>> I get the whole "XP code to too old to care" bit, but it seems odd to >>> >> take that "old code" and re-market it around compatibility and re- >> distribute it with free downloads for Win7 while saying "we won't patch >> old code." >> >>> t >>> >>> >>> -Original Message- From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- disclosure-boun...@lists.grok.org.uk] On Behalf Of Thor (Hammer of >> God) >> Sent: Wednesday, September 16, 2009 8:00 AM To: Eric C. Lukens; bugtraq@securityfocus.com Cc: full-disclos...@lists.grok.org.uk Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048? Thanks for the link. The problem here is that not enough >> information >> is given, and what IS given is obviously watered down to the point >> of >> being ineffective. The quote that stands out most for me: During the Q&A, however, Windows users repeatedly asked Microsoft's security team to explain why it wasn't patching XP, or if, in >> certain >> scenarios, their machines might be at risk. "We still use Windows XP and we do not use Windows Firewall," read one of the user questions. "We use a third-party vendor firewall product. Even assuming that we use the Windows Firewall, if there are services listening, such as remote desktop, wouldn't then Windows XP be vulnerable to this?" "Servers are a more likely target for this at
