Schannel and TLS 1.x padding vulnerability (CVE-2014-8730)

Hi all,
Is the implementation of TLS by Microsoft Secure Channel (Schannel) (http://msdn.microsoft.com/en-us/library/windows/desktop/aa380123%28v=vs.85%29.aspx) affected by "CVE-2014-8730 TLS 1.x padding vulnerability"?
Please see the following links for more details about this vulnerability:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8730
https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
Is there a confirmation from Microsoft that Schannel is not affected by this vulnerability?
Regards,
Sanjay

No, Microsoft SChannell is not affected.Only F5 products are affected:
http://www.securityfocus.com/bid/71549
Vadims Podāns, aka PowerShell CryptoGuy
My weblog: en-us.sysadmins.lv
PowerShell PKI Module: pspki.codeplex.com
PowerShell Cmdlet Help Editor pscmdlethelpeditor.codeplex.com
Check out new: SSL Certificate Verifier
Check out new:
PowerShell File Checksum Integrity Verifier tool.
i know some Windows 2008 System which are affected?! Why?

Similar Messages

OpenSSL vulnerability CVE-2014-0224

My customer want to know whether ASE is affected by the following OpenSSL vulnerability in http://www.openssl.org/news/secadv_20140605.txt
      SSL/TLS MITM vulnerability (CVE-2014-0224),
      DTLS recursion flaw (CVE-2014-0221)
      DTLS invalid fragment vulnerability (CVE-2014-0195)
      SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198)
      SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298)
      Anonymous ECDH denial of service (CVE-2014-3470)
Can you help me to confirm the above question?

You have clearly double posted this question in two groups.
So the first question goes back to you.
Are you Running SAP Applications on ASE, if so this is not the proper group?

Windows Server 2008 CVE-2014-8730 vulnerability

We've received our monthly vulnerability scan results on our production servers running Windows Server 2008 R2.
They are showing vulnerability to TSL POODLE, which is the subject of CVE-2014-8730.
In this article on Qualys, there is mention that Windows Server 2008 is vulnerable but Microsoft have not taken any action yet:
https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
Microsoft - We've seen reports that some older platforms (e.g., Windows 2008) appear vulnerable, but no apparent patterns or reliable information so far.
Is there any update on this issue as it's an exploitable vulnerability we would like to remediate.
Thanks,
Lyndon.

Hi Vivian,
The article cited is about a different issue.
In October 2014 there was an SSL v3 POODLE vulnerability, we have resolved this issue by disabling SSL v3 (as recommended).
The article your posted specifically references that issue (the article was published in October 2014).
In December 2014 there was another POODLE vulnerability announced that affected the TLS protocol.
A lot of major vendors have published patches for this issue, but Microsoft are yet do do so (as far as I know).
Hence by original question that has not been answered yet.
Regards,
Lyndon.

NX-OS ( n7000-s1-dk9.5.1.3.bin ) BASH VULNERABILITY - CVE-2014-6271 and CVE-2014-7169

Hi ,
Nexus 7000 evaluation for CVE-2014-6271 and CVE-2014-7169 , I am referring below link to check for NX OS - n7000-s1-dk9.5.1.3.bin
https://tools.cisco.com/bugsearch/bug/CSCur04856
5.1.3 is not mentioned in the affected list.Need help to know if 5.1 is affected with BASH Vulnerability .
Thanks for help in advance .

The concern with the bash shell is that services MAY be setup to run as
users which use those shells, and therefore be able to have things
injected into those shells. Nothing on NetWare uses bash by default,
because NetWare is not anything like Linux/Unix in its use of shells.
Sure, you can load bash for fun and profit on NetWare, but unless you
explicitly request it the bash.nlm file is never used. On NetWare I do
not think it is even possible to have any normal non-Bash environment
variable somehow be exported/inherited into a bash shell, though I've
never tried.
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

CSCuq79267 - UCS Apache 2.2 Vulnerability CVE-2014-0118

I too am seeing this same behavior. Nessus has found this, and 3 other, vulnerabilities with the Apache version provided by the UCS platform.
Any fixes in the works? We are currently running firmware 2.2(3c). The release notes for 2.2(3d) and 2.2(3e) do not address CVE-2014-0118.
EDIT:
2.2(3f) also does not address these vulnerabilities. Does the UCS version of Apache use the modules that are found faulty according to Nessus?
Nessus is also reporting the following CVEs related to this one: CVE-2013-6438, CVE-2014-0098, CVE-2013-5704, CVE-2014-0226, and CVE-2014-0231.

Hi,
Please refer this links,
Linux GHOST vulnerability (CVE-2015-0235) is not as scary as it looks | Symantec Connect
https://rhn.redhat.com/errata/RHSA-2015-0090.html
Regards,
S27

Mitigting SSL v3 POODLE Vulnerability (CVE-2014-3566)

Hi all,
Another day, another vulnerability. Feel like we are swimming against the tide.
Now, SSL v3 has been shown to be vulnerable (looks like a protocol issue, not an implementation issue, so patches are doubtful) and so I am looking at what we can do to mitigate this. Clients (such as IE, Firefox and Chrome (sort of)) can be set to disable SSL v3, but rolling this out across an Enterprise might not be that easy.
In IIS (that would be running TMS) you can switch off SSL v3 via a reg edit, but are there any knock on effect? What about the web services built into CODECs, MCUs and other infrastructure devices - can SSL v3 be switched off?
Look forward to the responses.
Cheers
Chris

Hi All,
This tidbit is not Cisco orientated per se, but some of you might find it useful (if you haven't found the info yourselves already (it's what I sent around to my team here):
There are many things you can do to mitigate this vulnerability, as you can also disable SSL3 in various clients (although this might affect communication with legacy systems)
Firefox – Version 34 (due for release at the end of November) will disable SSL v3 by default, but they have released a plug in that can disable this immediately. See https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
IE – You can turn off SSL 3 from the Settings -->Internet Options --> Advanced --> Security, section however, if you find that the options to check SSL/TLS are greyed out (as they are on my machine), this maybe a hang over from previous security software installation.
However, I will override this using GPO so domain joined PCs will have this setting updated. The GPO applied to the domain is:
Computer Setting --> Administrative Templates --> Windows Components --> Internet Explorer --> Internet Control Panel --> Advanced Page --> Turn Off Encryption Support = TLS 1.0, TLS 1.1, and TLS 1.2 ONLY
Chrome – This is a little more difficult. It seem you can only do this at this moment in time by adding a switch to the start-up command (you can modify the shortcut on either Windows or Mac). Check out https://zmap.io/sslv3/browsers.html

Bash patch did not fix vulnerability CVE-2014-7169, please fix

The latest patch for Bash bug that I just installed for Mavericks took care of the CVE-2014-6172 vulnerability though from my testing CVE-2014-7169 is still vulnerable. Please fix all Bash vulnerabilities soon.

Apple is on record as saying:
The vast majority of OS X users are not at risk to recently reported bash vulnerabilities," an Apple spokesperson told iMore. "Bash, a UNIX command shell and language included in OS X, has a weakness that could allow unauthorized users to remotely gain control of vulnerable systems. With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services.
You do not appear to be running any of these advanced UNIX services, so can you tell us exactly what your concern is?
Also, my testing shows that CVE-2014-7169 is fixed by using this test:
env X='() { (a)=>\' sh -c "echo date"; cat echo; rm ./echo
Did you forget to delete the file "echo" from your home folder by any chance?

IOS 7.06 SSL vulnerability CVE 2014-1266

Apple begins to fix the problems with SSL validation that can lead to MITM attacks. If they choose to move a step further they can also validate a DN which corresponds to a Directory entry and enable another layer of security. If certificates are going to be used for business and medical uses a failure to authenticate critical parts of the certificate detailed in RFC-5280 will lead to economic losses and potential medical errors.

What is your question for us, your fellow users, in these user to user support forums?

DNS vulnerability - CVE-2014-8500

Hello,
I have an mavericks server. where DNS service is active.
Have you got a patch for this security vulnerability (does not limit delegation chaining, which allows remote attackers to cause a denial of service) ?
Thanks
Gilles

You can do nothing, or you can configure BIND to relay queries for external hosts to another server instead of resolving them recursively.

[CVE-2014-6271] IronPort appliances affected by recent bash vulnerability?

http://threatpost.com/major-bash-vulnerability-affects-linux-unix-mac-os-x
Discussion?

Cisco has issued an official PSIRT notice for the GNU Bash Environmental Variable Command Injection Vulnerability (CVE-2014-6271), please refer all inquiries to:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140926-bash
Please refer to the expanded "Affected Products".
The following Cisco products are currently under investigation:
Cable Modems
Cisco CWMS
Network Application, Service, and Acceleration
Cisco ACE GSS 4400 Series Global Site Selector
Cisco ASA
Cisco GSS 4492R Global Site Selector
Network and Content Security Devices
Cisco IronPort Encryption Appliance
Cisco Ironport WSA
Routing and Switching - Enterprise and Service Provider
Cisco ACE Application Control Engine Module for the Cisco Catalyst 6500
Cisco ISM
Cisco NCS6000
Voice and Unified Communications Devices
Cisco Finesse
Cisco MediaSense
Cisco SocialMiner
Cisco Unified Contact Center Express (UCCX)
Products and services listed in the subsections below have had their exposure to this vulnerability confirmed. Additional products will be added to these sections as the investigation continues.

High Risk on DMP 4400 and 4310 "OpenSSL MITM CVE-2014-0224"

I cannot find a patch to fix the problem - is there a fix or should I create a TAC case?
DMM version - 5.3.0
4310 and 4400 - version 5.4.1

Here is what I received for the Dell Response to Openssl vulnerability.
After a couple of calls to technical support here is what I'm getting for my iDRAC7 getting flagged by Foundstone security scans for the vulnerability CVE-2014-0224:
" The OPEN SSL package used here contains multiple components, the component that is impacted and vulnerable is not being used, other components in this package are being used but aren't vulnerable".
"Dell has determined that the products listed in the attached document are not affected by the vulnerabilities. Some products have leveraged an older (but not vulnerable) OpenSSL module. These could be flagged by a scanner. Dell is currently working on updating the modules to a version that will not be flagged for these issues".
I've also attempted to upload the document, hopefully it can be viewed or downloaded.
If this post has helped you please rate it.
Thanks
2376.Dell-ResponseOpenSSLSecurityAdvisory_05_June_2014_final.pdf

CVE-2014-0513 hotfix for CS5?

Hello,
I was checking to see if there is a hotfix for CS5 regarding this vulnerability: CVE-2014-0513
I have searched however it seems to only be for CS6 so wondering if CVE-2014-0513 even applies to CS5?
Please advise.
Thanks
Reggie

Hi Jacob,
Is there a post or something that lists it? I went to the link you posted but I didn't see a mention of CS5 for CVE-2014-0513
The only thing I saw was for CS6
CVE-2014-0513 : Stack-based buffer overflow in Adobe Illustrator CS6 before 16.0.5 and 16.2.x before 16.2.2 allows remot…

CVE-2014-0224

Hi Everyone,
We have multiple switches being found that have this vulnerability CVE-2014-0224 known as OpenSSL Change CipherSpec Vulnerability. This affects our CATALYST 3750v2 switches is there any mitigations or workaround on this vulnerability other than upgrading its IOS.
Thank you
Sherwin

Firstly, I think you've posted this in the wrong section of the forums (TelePresence).
But, if you read the notices in detail, and especially the ones for each specific product, they will usually let you know a workaround if there is one.
For some of these vulnerabilities mentioned, you need to have physical access to the box, so making sure they're in a secured location is a good first step.

CSCur27617: AnyConnect vulnerable to POODLE attack (CVE-2014-3566) Win/Mac/Linux Question

CSCur27617: AnyConnect vulnerable to POODLE attack (CVE-2014-3566) Win/Mac/Linux
I wanted to know if the AnyConnect Secure Mobility Client would still be vulnerable to this if it was only connecting via SSL VPN (TLS) to an ASA that already has the workaround implemented on it (Disable SSLv3)?
Thanks,
Rob Miele

Hi Rob ,
According to the bug:
All versions of desktop AnyConnect for Mac OS X and Linux prior to 3.1.00495 are vulnerable , so Anyconnect 3.1.06.073 is safe from POODLE vulnerability
On the Anyconnect you can disable the SSL using Ikev2 instead of the SSL protocols , however as the bug mention , the client creates a paralel ssl tunnel to get updates and profile from the router.
If you're asking to disable SSLv3 on the router , unfortunately there is not code yet , the workaround is to disable the webvpn or upgrade the VPN client.
As well here is the officil advisory for the POODLE vulnerbility on Cisco Products.
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141015-poodle
Hope it helps
- Randy -

Trying to make the SSLv3 and TLS protocols coexist

I have a customer who wants to remove their vulnerability to (among other things) POODLE by getting rid of SSLv3 for communicating with external vendors via their PI system, by restricting traffic to using the TLS protocol.
Unfortunately, not all their External Partners can meet this requirement, so temporarily, they want to have SSLv3 traffic (where still necessary) over one port and TLS traffic over another. The plan is that there will also be fire wall rules restricting the IP addresses of "legacy partners" to the SSLv3 port. Following the instructions in 510007 - Setting up SSL on Application Server ABAP, they have installed SAPCRYPTOLIB version 5.5 and have set up the following configuration in DEFAULT.PFL:
* outgoing connections
ssl/ciphersuites = 135:HIGH
* incoming connections - TLS only protocol
icm/server_port_02 = PROT=HTTPS,PORT=443,SSLCONFIG=.........
icm/ssl_config_02 = CIPHERS=135:HIGH:MEDIUM:+e3DES
* incoming connections - SSL protocol
icm/server_port_01 = PROT=HTTPS,PORT=444,SSLCONFIG=.........
icm/ssl_config_01 = CIPHERS=196:HIGH:MEDIUM:+e3DES
So, what happens now is that f the External Partner attempts to initiate SSLv3 communications via port 443, then it fails. Yes, as currently setup, the External Partner can also initiate TLS communication over this port, but this is fine (for example, wireshark shows that the TLS protocol doesn't get downgraded to SSLv3).
The problem is that there is no way to control by port or customer whether outgoing connections are going to an SSLv3 or TLS only partner, so ssl/ciphersuites must allow for SSLv3 connections. This means that we can get a partner responding, over port 443, with the SSLv3 protocol without any error, thus allowing for an interception (ala POODLE).
Can we prevent SSLV3 traffic from succeeding over port 443, regardless of who initiates it ?

Hi,
I don't think that PI provides capabilities of setting allowed cipher suites per communication channel. Hence you can try to do this outside of SAP which brings additional complexity to your landscape. You could introduce a reverse proxy that would have hostnames like customer1.weakssl.local, customer2.weakssl.local for every customer that still needs SSLv3. This proxy would accept only TLS connection so you would be able to set ssl/client_ciphersuites to allow only strong suites. Your PI system would connect to partners with TLS or this reverse proxy only. The reverse proxy would drop TLS connection from PI and establish new connection SSLv3 between itself and customer. Hence PI would never use SSLv3 and the allowed SSLv3 outbound connections would be controlled by reverse proxy configuration.
PI ------------TLS----------------> Client that supports TLS
PI ------------TLS----->Reverse Proxy -----------SSLv3 ---------> Client that does not support TLS
Another disadvantage is that you will have to update PI config to connect via new reverse proxy instead of direct connection to customer's system.
Cheers

Schannel and TLS 1.x padding vulnerability (CVE-2014-8730)

Similar Messages

Maybe you are looking for