Information Security

Vulnerability Pipes

Vuln: Microsoft Windows CVE-2014-4114 OLE Package Manager Remote Code Execution Vulnerability

Windows Security - 3 hours 41 min ago
Microsoft Windows CVE-2014-4114 OLE Package Manager Remote Code Execution Vulnerability
Categories: Vulnerability Pipes

Apple Multiple Security Updates, (Mon, Oct 20th)

Other Security - 7 hours 12 min ago


Apple released security update today for iOS 8 and Apple TV 7.

iOS 8.1 (APPLE-SA-2014-10-20-1 iOS 8.1) is now available for iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later, to addresses the following:

Bluetooth CVE-2014-4448
House Arrest CVE-2014-4448
iCloud Data Access CVE-2014-4449
Keyboards CVE-2014-4450
Secure Transport CVE-2014-3566

Apple TV 7.0.1 (APPLE-SA-2014-10-20-2 Apple TV 7.0.1) is now available for Apple TV 3rd generation and later, to address the following:

Bluetooth CVE-2014-4428
Secure Transport CVE-2014-3566

[1] https://support.apple.com/kb/HT1222

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Teaching SEC 503 end of October in Ottawa

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

Vuln: Microsoft Windows FAT32 Disk Partition Driver CVE-2014-4115 Local Privilege Escalation Vulnerability

Windows Security - Sun, 10/19/2014 - 19:00
Microsoft Windows FAT32 Disk Partition Driver CVE-2014-4115 Local Privilege Escalation Vulnerability
Categories: Vulnerability Pipes

Vuln: Microsoft .NET Framework ClickOnce CVE-2014-4073 Remote Privilege Escalation Vulnerability

Windows Security - Sun, 10/19/2014 - 19:00
Microsoft .NET Framework ClickOnce CVE-2014-4073 Remote Privilege Escalation Vulnerability
Categories: Vulnerability Pipes

Vuln: Microsoft .NET Framework CVE-2014-4122 ASLR Security Bypass Vulnerability

Windows Security - Sun, 10/19/2014 - 19:00
Microsoft .NET Framework CVE-2014-4122 ASLR Security Bypass Vulnerability
Categories: Vulnerability Pipes

Microsoft MSRT October Update, (Sun, Oct 19th)

Windows Security - Sun, 10/19/2014 - 10:50

This past week Microsoft MSRT push contains detections/removals for several widely used APT tools. The coalition (led by Novetta) that brought about the inclusions of these tools in this month MSRT, are encouraging enterprises to push/execute this month MSRT update. Some of malware included in this month MSRT update have a preliminary report posted here.

If you are using either Snort or Sourcefire, the ruleIDs to detect some of the threat/family in this month MSRT release are listed below and can be downloaded from Snort or from Sourcefire VRT subscription.

Derusbi -- 20080
Fexel -- 29459
Hikit -- 30948
DeputyDog -- 28493
Hydraq -- 16368, 21304
DarkMoon -- 7816, 7815, 7814, 7813, 12715, 12724
Zxshell -- 32180, 32181

[1] http://blogs.technet.com/b/mmpc/archive/2014/10/14/msrt-october-2014-hikiti.aspx
[2] http://www.microsoft.com/security/pc-security/malware-removal.aspx
[3] http://novetta.com/commercial/news/resources/
[4] https://www.snort.org/downloads/#rule-downloads

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Teaching SEC 503 end of October in Ottawa

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

TA14-290A: SSL 3.0 Protocol Vulnerability and POODLE Attack

Other Security - Fri, 10/17/2014 - 11:27
Original release date: October 17, 2014 | Last revised: October 20, 2014
Systems Affected

All systems and applications utilizing the Secure Socket Layer (SSL) 3.0 with cipher-block chaining (CBC) mode ciphers may be vulnerable. However, the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack demonstrates this vulnerability using web browsers and web servers, which is one of the most likely exploitation scenarios.

Overview

US-CERT is aware of a design vulnerability found in the way SSL 3.0 handles block cipher mode padding. The POODLE attack demonstrates how an attacker can exploit this vulnerability to decrypt and extract information from inside an encrypted transaction.

Description

The SSL 3.0 vulnerability stems from the way blocks of data are encrypted under a specific type of encryption algorithm within the SSL protocol. The POODLE attack takes advantage of the protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 and then leverages this new vulnerability to decrypt select content within the SSL session. The decryption is done byte by byte and will generate a large number of connections between the client and server.

While SSL 3.0 is an old encryption standard and has generally been replaced by Transport Layer Security (TLS) (which is not vulnerable in this way), most SSL/TLS implementations remain backwards compatible with SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. Even if a client and server both support a version of TLS the SSL/TLS protocol suite allows for protocol version negotiation (being referred to as the “downgrade dance” in other reporting). The POODLE attack leverages the fact that when a secure connection attempt fails, servers will fall back to older protocols such as SSL 3.0. An attacker who can trigger a connection failure can then force the use of SSL 3.0 and attempt the new attack. [1]

Two other conditions must be met to successfully execute the POODLE attack: 1) the attacker must be able to control portions of the client side of the SSL connection (varying the length of the input) and 2) the attacker must have visibility of the resulting ciphertext. The most common way to achieve these conditions would be to act as Man-in-the-Middle (MITM), requiring a whole separate form of attack to establish that level of access.

These conditions make successful exploitation somewhat difficult. Environments that are already at above-average risk for MITM attacks (such as public WiFi) remove some of those challenges.

Impact

The POODLE attack can be used against any system or application that supports SSL 3.0 with CBC mode ciphers. This affects most current browsers and websites, but also includes any software that either references a vulnerable SSL/TLS library (e.g. OpenSSL) or implements the SSL/TLS protocol suite itself. By exploiting this vulnerability in a likely web-based scenario, an attacker can gain access to sensitive data passed within the encrypted web session, such as passwords, cookies and other authentication tokens that can then be used to gain more complete access to a website (impersonating that user, accessing database content, etc.).

Solution

There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is fundamental to the protocol; however, disabling SSL 3.0 support in system/application configurations is the most viable solution currently available.

Some of the same researchers that discovered the vulnerability also developed a fix for one of the prerequisite conditions; TLS_FALLBACK_SCSV is a protocol extension that prevents MITM attackers from being able to force a protocol downgrade. OpenSSL has added support for TLS_FALLBACK_SCSV to their latest versions and recommend the following upgrades: [2]

  • OpenSSL 1.0.1 users should upgrade to 1.0.1j.
  • OpenSSL 1.0.0 users should upgrade to 1.0.0o.
  • OpenSSL 0.9.8 users should upgrade to 0.9.8zc.

Both clients and servers need to support TLS_FALLBACK_SCSV to prevent downgrade attacks.

Other SSL 3.0 implementations are most likely also affected by POODLE. Contact your vendor for details. Additional vendor information may be available in the National Vulnerability Database (NVD) entry for CVE-2014-3566 [3] or in CERT Vulnerability Note VU#577193. [4]

References Revision History
  • October 17, 2014 Initial Release
  • October 20, 2014 Added CERT Vulnerability Note VU#577193 to the Solution section

This product is provided subject to this Notification and this Privacy & Use policy.


Categories: Vulnerability Pipes

Apple Updates (not just Yosemite), (Fri, Oct 17th)

Other Security - Fri, 10/17/2014 - 07:42

Apple yesterday released the latest version of its operating system, OS X 10.10 Yosemite. As usual, the new version of the operating system does include a number of security related bug fixes, and Apple released these fixes for older versions of OS X today.

This update, Security Update 2014-005 is available for versions of OS X back to 10.8.5 (Mountain Lion).

Among the long list of fixes, here a couple of highlights:

Apple doesnt turn off SSLv3 in this release, but restricts it to non-CBC ciphers, limiting its exposure to attacks like POODLE and BEAST. The list of trusted certificate authorities has also been updates [2]

802.1x no longer supports LEAP by default due to weaknesses in this authentication method.

The bash fix, that was released as a standalone fix earlier to counter Shellshock, is included in this update.

An arbitrary code execution vulnerability in CUPS was fixed. (CVE-2014-3537)

And a quick note about OS 10.10 Yosemite:

After installing it, all security relevant settings Ichecked where untouched (good!). Among security relevant software, GPGMailwill not work with Yosemite yet, but according to the developers, a fix is in the work and may be release in a few weeks, but GPGMail may no longer be free. If you rely on software that you compiled with MacPorts: Wait for the release of XCode 6.1, as it is required to recompile the software for OS X 10.10. In general, it is adviced that you FIRST update all your software and then upgrade to Yosemite. Little Snitch, another popular piece of security software for OS X, works well with Yosemite, but I recommend you turn off the network filter during the upgrade (it works with it enabled, but you need to approve a lot of new connections from new software).

[1]http://support.apple.com/kb/HT1222
[2]http://support.apple.com/kb/HT6005

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

Vuln: Apache Xalan-Java Library CVE-2014-0107 Security Bypass Vulnerability

Linux Security - Thu, 10/16/2014 - 19:00
Apache Xalan-Java Library CVE-2014-0107 Security Bypass Vulnerability
Categories: Vulnerability Pipes

Logging SSL, (Thu, Oct 16th)

Linux Security - Thu, 10/16/2014 - 11:37

With POODLE behind us, it is time to get ready for the next SSL firedrill. One of the questions that keeps coming up is which ciphers and SSL/TLS versions are actually in use. If you decide to turn off SSLv3 or not depends a lot on who needs it, and it is an important answer to have ready should tomorrow some other cipher turn out to be too weak.

But keep in mind that it is not just numbers that matter. You also need to figure out who the outliers are and how important (or dangerous?) they are. So as a good start, try to figure out how to log SSL/TLS versions and ciphers. There are a couple of options to do this:

In Apache, you can log the protocol version and cipher easily by logging the respective environment variable [1] . For example:
CustomLog logs/ssl_request_log %t %h \{User-agent}i\%{SSL_PROTOCOL}x %{SSL_CIPHER}x

Logs SSL protocol and cipher. You can add this to an existing access log, or create a new log. If you decide to log this in its own log, I suggest you add User-Agent and IP Address (as well as time stamp).

In nginx, you can do the same by adding$ssl_cipher $ssl_protocolto the log_format directive in your nginx configuration. For example:

log_format ssl $remote_addr $http_user_agent $ssl_cipher $ssl_protocol

Should give you a similar result as for apache above.

If you have a packet sniffer in place, you can also use tshark to extract the data. With t-shark, you can actually get a bit further. You can log the client hello with whatever ciphers the client proposed, and the server hello which will indicate what cipher the server picked.

tshark -r ssl -2R ssl.handshake.type==2 or ssl.handshake.type==1 -T fields -e ssl.handshake.type -e ssl.record.version -e ssl.handshake.version -e ssl.handshake.ciphersuite

For extra credit log the host name requested in the client hello via SNI and compare it to the actual host name the client connects to.

Now you can not only collect Real Data as to what ciphers are needed, but you can also look for anomalies. For example, user agents that request very different ciphers then other connections that claim to originate from the same user agent. Or who is asking for weak ciphers? Maybe a sign for an SSL downgrade attack? Or an attack tool using and older SSL library...

[1] http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#logformats[2]

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

POODLE: Turning off SSLv3 for various servers and client. , (Wed, Oct 15th)

Linux Security - Wed, 10/15/2014 - 12:29

Before you start: While adjusting your SSL configuration, you should also check for various other SSL related configuration options. A good outline can be found at http://bettercrypto.org as well as at http://ssllabs.com (for web servers in particular)

Here are some configuration directives to turn off SSLv3 support on servers:

Apache: Add -SSLv3 to the SSLProtocol line. It should already contain -SSLv2 unless you list specific protocols.

nginx: list specific allowed protocols in the ssl_protocols line. Make sure SSLv2

Postfix: Disable SSLv3 support in the smtpd_tls_manadatory_protocols configuration line. For example: smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3

Dovecot: similar, disable SSLv2 and SSLv3 in the ssl_protocols line. For example: ssl_protocols =!SSLv2 !SSLv3

HAProxy Server: the bind configuration line should include no-sslv3 (this line also lists allowed ciphers)

puppet:seehttps://github.com/stephenrjohnson/puppetmodule/commit/1adb73f9a400cb5e91c4ece1c6166fd63004f448 for instructions

For clients, turning off SSLv3 can be a bit more tricky, or just impossible.

Google Chrome: you need to start Google Chrome with the --ssl-version-min=tls1 option.

Internet Explorer: You can turn off SSLv3 support in the advanced internet option dialog.

Firefox: check the security.tls.version.min setting in about:config and set it to 1. Oddly enough, in our testing, the default setting of 0 will allow SSLv3 connections, but refuses to connect to our SSLv3 only server.

For Microsoft Windows, you can use group policies. For details see Microsofts advisory:https://technet.microsoft.com/en-us/library/security/3009008.aspx

To test, continue to use our POODLE Test page at https://poodletest.com or the QualysSSLLabs page at https://ssllabs.com

To detect the use of SSLv3, you can try the following filters:

tshark/wireshark display filters:ssl.handshake.version==0x0300

tcpdump filter: (1) accounting for variable TCP header length:tcp[((tcp[12]4)*4)+9:2]=0x0300
(2) assuming TCP header length is 20:tcp[29:2]=0x0300

We will also have a special webcast at 3pm ET. For details see

https://www.sans.org/webcasts/about-poodle-99032

the webcast will probably last 20-30 minutes and summarize the highlights of what we know so far.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

POODLE: Turning off SSLv3 for various servers and client. , (Wed, Oct 15th)

Windows Security - Wed, 10/15/2014 - 12:29

Before you start: While adjusting your SSL configuration, you should also check for various other SSL related configuration options. A good outline can be found at http://bettercrypto.org as well as at http://ssllabs.com (for web servers in particular)

Here are some configuration directives to turn off SSLv3 support on servers:

Apache: Add -SSLv3 to the SSLProtocol line. It should already contain -SSLv2 unless you list specific protocols.

nginx: list specific allowed protocols in the ssl_protocols line. Make sure SSLv2

Postfix: Disable SSLv3 support in the smtpd_tls_manadatory_protocols configuration line. For example: smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3

Dovecot: similar, disable SSLv2 and SSLv3 in the ssl_protocols line. For example: ssl_protocols =!SSLv2 !SSLv3

HAProxy Server: the bind configuration line should include no-sslv3 (this line also lists allowed ciphers)

puppet:seehttps://github.com/stephenrjohnson/puppetmodule/commit/1adb73f9a400cb5e91c4ece1c6166fd63004f448 for instructions

For clients, turning off SSLv3 can be a bit more tricky, or just impossible.

Google Chrome: you need to start Google Chrome with the --ssl-version-min=tls1 option.

Internet Explorer: You can turn off SSLv3 support in the advanced internet option dialog.

Firefox: check the security.tls.version.min setting in about:config and set it to 1. Oddly enough, in our testing, the default setting of 0 will allow SSLv3 connections, but refuses to connect to our SSLv3 only server.

For Microsoft Windows, you can use group policies. For details see Microsofts advisory:https://technet.microsoft.com/en-us/library/security/3009008.aspx

To test, continue to use our POODLE Test page at https://poodletest.com or the QualysSSLLabs page at https://ssllabs.com

To detect the use of SSLv3, you can try the following filters:

tshark/wireshark display filters:ssl.handshake.version==0x0300

tcpdump filter: (1) accounting for variable TCP header length:tcp[((tcp[12]4)*4)+9:2]=0x0300
(2) assuming TCP header length is 20:tcp[29:2]=0x0300

We will also have a special webcast at 3pm ET. For details see

https://www.sans.org/webcasts/about-poodle-99032

the webcast will probably last 20-30 minutes and summarize the highlights of what we know so far.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

October 2014 Critical Patch Update Released, (Wed, Oct 15th)

Other Security - Wed, 10/15/2014 - 03:17

Oracle have released itscritical patch update for October 2014, this series of patches will provide fixes for 154 vulnerabilities across a number of product families including: Oracle Database, Oracle Fusion Middleware, Oracle Enterprise Manager Grid Control, Oracle E-Business Suite, Oracle Supply Chain Product Suite, Oracle PeopleSoft Enterprise, Oracle JDEdwards EnterpriseOne, Oracle Communications Industry Suite, Oracle Retail Industry Suite, Oracle Health Sciences Industry Suite, Oracle Primavera, Oracle Java SE, Oracle and Sun Systems Product Suite, Oracle Linux and Virtualization, and Oracle MySQL.

For more details please refer to the following link:

http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

OpenSSL: SSLv3 POODLE Vulnerability Official Release, (Tue, Oct 14th)

Other Security - Tue, 10/14/2014 - 19:23

Finally we got an official announcement. For all the details, jump straight to the original announcement [1]. Below see the TL;DR; version:

The problem is limited to SSLv3. SSLv3 is often considered similar to TLSv1.0, but the two protocols are different.

SSLv3 had issues in the past. Remember the BEAST attack? It was never resolved (other then moving to TLS 1.1/2). The only alternative was to use a stream cipher like RC4, which had its own problems.

But this POODLE issue is different. With block ciphers, we have a second problem: What if the block to be encrypted is too short? In this case, padding is used to make up for the missing data. Since the padding isnt really considered part of the message, it is not covered by the MAC (message authorization code) that verified message integrity.

So what does this mean in real live? The impact is similar to the BEAST attack. An attacker may either play MitM, or may be able to decrypt parts of a message if the attacker is able to inject data into the connection just like in the BEAST attack. The attack allows one to decrypt one byte at a time, if the attacker is able to inject messages right after that byte that include only padding.

What should you do: Disable SSLv3. There is no patch for this. SSLv3 has reached the end of its useful life and should be retired.

This isnt a patch now. Give it some time, test it carefully, but get going with it. The other problem is that this is a client and a server issue. You need to disable SSLv3 on either. Start with the servers for highest impact, but then see what you can do about clients.

The other option to fix this problem is to use SSL implementations that take advantage of the TLS_FALLBACK_SCSV feature. This feature notifies the other side that you first tried the stronger cipher. This way, they can reject the downgrade attempt that may have been introduced by a MitM attack. But it isnt clear which implementations use this feature at this point, and which dont. A patch for OpenSSL 1.0.1 was released earlier today implementing TLS_FALLBACK_SCSV

FAQ

To test if your server is vulnerable: Use https://ssltest.com

To test if your client is vulnerable: We setup a test page at https://sslv3.dshield.org:444/index.html . If you can connect, then your client supports SSLv3 .

So far, we tested :

Supporting SSLv3:
Safari and Chrome on OS X
Internet Explorer 11, Chrome 37on Windows 7

Not Supporting SSLv3:
Firefox 32 on OS X.
Firefox 32 on Windows 7

To turn off SSLv3 support in Internet Explorer 11:

Setting - Internet Options - Advanced Tab - Uncheck SSLv3 under Security.

">[1]https://www.openssl.org/~bodo/ssl-poodle.pdf

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

OpenSSL: SSLv3 POODLE Vulnerability Official Release, (Tue, Oct 14th)

Windows Security - Tue, 10/14/2014 - 19:23

Finally we got an official announcement. For all the details, jump straight to the original announcement [1]. Below see the TL;DR; version:

The problem is limited to SSLv3. SSLv3 is often considered similar to TLSv1.0, but the two protocols are different.

SSLv3 had issues in the past. Remember the BEAST attack? It was never resolved (other then moving to TLS 1.1/2). The only alternative was to use a stream cipher like RC4, which had its own problems.

But this POODLE issue is different. With block ciphers, we have a second problem: What if the block to be encrypted is too short? In this case, padding is used to make up for the missing data. Since the padding isnt really considered part of the message, it is not covered by the MAC (message authorization code) that verified message integrity.

So what does this mean in real live? The impact is similar to the BEAST attack. An attacker may either play MitM, or may be able to decrypt parts of a message if the attacker is able to inject data into the connection just like in the BEAST attack. The attack allows one to decrypt one byte at a time, if the attacker is able to inject messages right after that byte that include only padding.

What should you do: Disable SSLv3. There is no patch for this. SSLv3 has reached the end of its useful life and should be retired.

This isnt a patch now. Give it some time, test it carefully, but get going with it. The other problem is that this is a client and a server issue. You need to disable SSLv3 on either. Start with the servers for highest impact, but then see what you can do about clients.

The other option to fix this problem is to use SSL implementations that take advantage of the TLS_FALLBACK_SCSV feature. This feature notifies the other side that you first tried the stronger cipher. This way, they can reject the downgrade attempt that may have been introduced by a MitM attack. But it isnt clear which implementations use this feature at this point, and which dont. A patch for OpenSSL 1.0.1 was released earlier today implementing TLS_FALLBACK_SCSV

FAQ

To test if your server is vulnerable: Use https://ssltest.com

To test if your client is vulnerable: We setup a test page at https://sslv3.dshield.org:444/index.html . If you can connect, then your client supports SSLv3 .

So far, we tested :

Supporting SSLv3:
Safari and Chrome on OS X
Internet Explorer 11, Chrome 37on Windows 7

Not Supporting SSLv3:
Firefox 32 on OS X.
Firefox 32 on Windows 7

To turn off SSLv3 support in Internet Explorer 11:

Setting - Internet Options - Advanced Tab - Uncheck SSLv3 under Security.

">[1]https://www.openssl.org/~bodo/ssl-poodle.pdf

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

Vuln: Microsoft Internet Explorer CVE-2014-4130 Remote Memory Corruption Vulnerability

Windows Security - Tue, 10/14/2014 - 19:00
Microsoft Internet Explorer CVE-2014-4130 Remote Memory Corruption Vulnerability
Categories: Vulnerability Pipes

Vuln: Microsoft Internet Explorer CVE-2014-4138 Remote Memory Corruption Vulnerability

Windows Security - Tue, 10/14/2014 - 19:00
Microsoft Internet Explorer CVE-2014-4138 Remote Memory Corruption Vulnerability
Categories: Vulnerability Pipes

Vuln: Microsoft Internet Explorer CVE-2014-4141 Remote Memory Corruption Vulnerability

Windows Security - Tue, 10/14/2014 - 19:00
Microsoft Internet Explorer CVE-2014-4141 Remote Memory Corruption Vulnerability
Categories: Vulnerability Pipes

Vuln: Microsoft Office Word File Processing CVE-2014-4117 Remote Code Execution Vulnerability

Windows Security - Tue, 10/14/2014 - 19:00
Microsoft Office Word File Processing CVE-2014-4117 Remote Code Execution Vulnerability
Categories: Vulnerability Pipes

Vuln: Apache Commons FileUpload CVE-2014-0050 Denial Of Service Vulnerability

Linux Security - Tue, 10/14/2014 - 19:00
Apache Commons FileUpload CVE-2014-0050 Denial Of Service Vulnerability
Categories: Vulnerability Pipes
Syndicate content