Slashdot Mirror

HPKP was removed because it's hard to use correctly, impossible to recover if certain bad things happen, and therefore almost never deployed. It was not some grand conspiracy to do with advertisers. Using many changing domain names doesnâ(TM)t matter to HPKP, which was designed to prevent attacks on TLS certificates.

Homograph attacks are different domains using visually identical Unicode characters to another legitimate domain to confuse users into thinking they are on the correct site. HPKP prevents attacks on TLS for the same domain. They are two completely different things.

Based on this, I'm pretty sure local is not a requirement. I presume that's merely how they tested the exploit. And I presume a lot of companies which are running Linux Cloud farms aren't happy that systemd, for all its supposed management benefits, allows for such exploits. But, then, Linux (and Windows) root exploits are par the course for most people, I guess. :/

https://www.qualys.com/2019/01... :

2018-11-26: Advisory sent to Red Hat Product Security (as recommended by
https://github.com/systemd/sys...).

2018-12-26: Advisory and patches sent to linux-distros@openwall.

2019-01-09: Coordinated Release Date (6:00 PM UTC).

In case you're interested to know the breakdown...

Based on our research, we recommend that the affected operating systems:

- Increase the size of the stack guard-page to at least 1MB, and allow system administrators to easily modify this value (for example, grsecurity/PaX introduced /proc/sys/vm/heap_stack_gap in 2010). This first, short-term solution is cheap, but it can be defeated by a very large stack-based buffer.

- Recompile all userland code (ld.so, libraries, binaries) with GCC's "-fstack-check" option, which prevents the stack-pointer from moving into another memory region without accessing the stack guard-page (it writes one word to every 4KB page allocated on the stack). This second, long-term solution is expensive, but it cannot be defeated (even if the stack guard-page is only 4KB, one page) -- unless a vulnerability is discovered in the implementation of the stack guard-page or the "-fstack-check" option.

That was one of the recommendations. Finding large stack allocations, in setuid binaries, that don't write to the allocated memory is hard.

This is because those are the Operating Systems they tested. They indicate "Other operating systems and architectures may be vulnerable too, but we have not researched any of them yet: please refer to your vendor’s official statement about the Stack Clash for more information." in their blog on the subject.". In other words, Microsoft products are likely just as vulnerable (unless you think all these developers for all these OSs didn't think properly mitigate this, but Microsoft did.) Also, note that Linux has implemented a fix for this type of attack, it just turns out it wasn't good enough. They are increasing the stack guard size that they already implemented to deal with it now.

https://www.qualys.com/2017/06...

Wonder no more, here's the actual technical description of the problem that includes attacks on non-Linux OSes: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt.

Slashdot editors: this link should have been in the summary. It's the relevant one to technical users interested in what the attack actually is.

"The Stack Clash is a vulnerability in the memory management of several operating systems. It affects Linux, OpenBSD, NetBSD, FreeBSD and Solaris, on i386 and amd64. It can be exploited by attackers to corrupt memory and execute arbitrary code."

https://blog.qualys.com/securi...

Go read http://undeadly.org/cgi?action... and https://www.qualys.com/2016/01... Come back and maybe (just maybe) you'll find what exactly is wrong in your post.

You make it sound like no one has ever hacked a hypervisor.

The recommendation to web site hosts to address the beast attack was to go back to RC4 because the browsers supported it and the servers supported it. The right thing would be to go forward to a decent mode like CCM or GCM, but that would require the browsers to support them and they don't universally support those modes.
E.G.
https://blogs.gnome.org/mcatan...
https://community.qualys.com/b...

Firefox has already done this. Since Firefox 37 the default preference does not allow fall back to TLS 1.0 or 1.1. So if your bank's website is not using TLS 1.2 then you will not be able to connect to it. There is no user friendly UI to change the setting, but you can change the fall back setting using the about:config mechanism. Check the release notes here - https://www.mozilla.org/en-US/... Also SSL labs has already planned to give low grade to websites using RC4 over next few months - https://community.qualys.com/b... You can check the status of your baks security infrastructure with ssl labs scanning tool and complain about it in bank support forum - https://www.ssllabs.com/ssltes... The client I worked for has same problem with some websites and hence started getting calls from customers. Thankfully they have quickly recognised the potential loss of business and are working on upgrading the infrastructure.

Thankfully, this looks to be an implementation issue and not a protocol issue like SSL had. From the blog of the folks who run that SSL test:

As problems go, this one should be easy to fix. [...] [E]ven though TLS is very strict about how its padding is formatted, it turns out that some TLS implementations omit to check the padding structure after decryption. Such implementations are vulnerable to the POODLE attack even with TLS. [...] According to our most recent SSL Pulse scan (which hasn’t been published yet), about 10% of the servers are vulnerable to the POODLE attack against TLS.

The impact of this problem is similar to that of POODLE, with the attack being slightly easier to execute–no need to downgrade modern clients down to SSL 3 first, TLS 1.2 will do just fine.

This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken. An IETF draft to prohibit RC4 is in Last Call at the moment but it would be wrong to believe that RC4 is uniquely bad. While RC4 is fundamentally broken and no implementation can save it, attacks against MtE-CBC ciphers have repeatedly been shown to be far more practical. Thankfully, TLS 1.2 support is about to hit 50% at the time of writing.

I am terribly confused. Is or isn't worth upgrading to TLS 1.2?

I am stuck with TLS 1.0 on FireFox v10 ESR. Tried v24, and it's just ick with the one of the bugs that I 'first' encounted with v17 with my "setup". "Up and down shaking" with my tab 'setup' if you're curious. I use two rows of tabs. And v31 is totally broken in a frustrating way. I may be able to manage v24 if I'm forced to, but I don't want to upgrade if I don't have to. (I wish Mozilla would just do security patches for all the ESRs. Not bug patches, but security patches. Wasn't that the point of having an ESR with which to begin?)

tl;dr For those of us on TLS 1.0, do we need to do anything, or is it something only server/website admins need to do?

The absence of competition in this area drives many to Google, making data siphoning easy for the NSA.

For me, I do not use any provider that has their HQ inside the United States of America.

And ... in order to retard NSA's snooping in my traffic, I deploy SSL forward secrecy on my sites.

Anyone who wants to know about forward secrecy please visit https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy to get more info

What makes you so sure?

That they are STILL trying to hide something BIG? Years in the telecom and ISP business, NSA-watching since the Internet went global and way before. I am one of those people who might have become a spook, though I am glad I did not. From its all-to-brief brief mention in David Kahn's The Codebreakers [1967] which I carried around as a kid like some overstuffed bible, my interest was piqued by James Bamford's Puzzle Palace [1982] which introduced the world to the topic of the 'piggyback slurp' and laid out directly NSA's intentions to tap the world. The whole world -- Charter be damned -- from the start.

A few anecdotes from good friends in the telecommunications trade who alluded to special cordoned-off spaces within AT&T's Magens Point cable terminus in St. Thomas US Virgin Islands, drunken conversation in bars with reminders not to speak of such things... a rather suspicious 'underwater landslide' fiber outage between St. Thomas and Puerto Rico c.1995, which I suspected at the time might involve a submarine because a telco friend noticed that after all his voice circuits were back there was an eyebrow-raising 'unusually long period' before the data circuits came up, even though they were physically interspersed and not supposed to be broken out at the carrier level... circumstantial stuff, sure. Pure speculation is as fascinating as the real thing.

Since then, revelations about Room 614A and Hepting vs. AT&T, the little mouse who could have roared all the way to the Supreme Court, had they not declined to hear the case.

I'm not talking about individual stakeouts or FISA warrants or occasional 'oopsies' of a few domestic intercepts. I'm discussing large scale Tier 1 total interception of data with selective routing and forwarding of target traffic onto side channels via 'dark' or leased fiber on a scale that is approaching 'total'. This includes voice too: terrestrially trunked cell calls and landline (there is practically no difference these days, it's all turkeyfart compressed).

Which is why I posted here back in June my theory that PRISM slides were made as part of a limited hang-out. I came to this conclusion because I found the allegation that Internet service providers named grant direct back-doors to NSA to be preposterous (and still do, too much risk of exposure by now). The purpose of the hang-out was for Google and company to discredit the allegations honesty to relegate it to 'hoax' status... and provide a topic that diverts attention away from the total-tap-slurp operation.

Steve Gibson of Gibson Research has come up with another theory that I find interesting, it may fit Occam's Razor better than my own. He presented it recently in Security Now #408: The State of Surveillance, audio and full transcript available. GOOD STUFF. His angle is that "direct access to their servers" means all unencrypted SMTP-mail and HTTP from tap points directly upstream. It is all about fiber and taps. Taps are about splitting light... and that is what prisms do.

If you have a good traffic tap and encrypted intercepts, add a bit of coercion for the providers to divulge their private SSL keys and they can replay the past SSL sessions they have gathered.

It is time for everyone to learn about and implement Perfect Forward Secrecy.

Thar be dragins in our midst. Slay them.
NSA and the Desolation of Smaug

The good news is that if the web servers use forward secrecy in the SSL encryption ( https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy ), then an attacker who has the private key is not able to decrypt a connection he has passively eavesdropped on. An active man-in-the-middle attack is required in order to listen in on the connection.

Ixquick and Startpage offer better SSL than DuckDuckGo. They have TLS 1.1 and 1.2 (DDG has only 1.0), and have enabled TLS 1.2 256-bit ciphers with a higher priority. I think they still keep RC4 for TLS 1.0 and SSL 3.0 to mitigate the BEAST attack for CBC ciphers, since 128-bit RC4 is the better devil until everybody moves to TLS 1.2.

Ixquick/Startpage seem to have servers in both the US and Europe.

https://www.ssllabs.com/ssltest/analyze.html?d=startpage.com&s=69.28.209.119

https://www.ssllabs.com/ssltest/analyze.html?d=ixquick.com&s=69.90.210.8

Ixquick and Startpage offer better SSL than DuckDuckGo. They have TLS 1.1 and 1.2 (DDG has only 1.0), and have enabled TLS 1.2 256-bit ciphers with a higher priority. I think they still keep RC4 for TLS 1.0 and SSL 3.0 to mitigate the BEAST attack for CBC ciphers, since 128-bit RC4 is the better devil until everybody moves to TLS 1.2.

Ixquick/Startpage seem to have servers in both the US and Europe.

https://www.ssllabs.com/ssltest/analyze.html?d=startpage.com&s=69.28.209.119

https://www.ssllabs.com/ssltest/analyze.html?d=ixquick.com&s=69.90.210.8

Almost all parts of SSL in common use are compromised to some degree.

The BEAST attack (theoretically) compromises every common and strong SSL cypher other than RC4 and the march to newer TLS versions that offer protection for them is slow, not least in the webserver packages common Linux distros come with.

As has been mentioned, no recompiling is necessary:

https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls

If you're just running a "1 apache site", that satisfying green bar or "A grade" is just a few config stanzas and a restart away.

I'm not running one, but four. Still, not a big deal. I thought I'd check it out their reporting tool which tells me:

BEAST attack -- Vulnerable INSECURE (more info)
Secure Renegotiation -- Not supported ACTION NEEDED (more info)
Insecure Renegotiation -- Supported INSECURE (more info)

That's fine and dandy. But each of the "more info" links goes to a blog posting that discusses the topic just a little bit, and only one of them provides enough information to fix it. Thankfully our sites aren't handling financial transactions of any kind, or I might have to actually locate a fix... how is everyone else fixing this (esp. the renegotiation vulnerability) if there's nothing available to remedy it except for disabling renegotiation?

If you're just running a "1 apache site", that satisfying green bar or "A grade" is just a few config stanzas and a restart away.

I'm not running one, but four. Still, not a big deal. I thought I'd check it out their reporting tool which tells me:

BEAST attack -- Vulnerable INSECURE (more info)
Secure Renegotiation -- Not supported ACTION NEEDED (more info)
Insecure Renegotiation -- Supported INSECURE (more info)

That's fine and dandy. But each of the "more info" links goes to a blog posting that discusses the topic just a little bit, and only one of them provides enough information to fix it. Thankfully our sites aren't handling financial transactions of any kind, or I might have to actually locate a fix... how is everyone else fixing this (esp. the renegotiation vulnerability) if there's nothing available to remedy it except for disabling renegotiation?

If you're just running a "1 apache site", that satisfying green bar or "A grade" is just a few config stanzas and a restart away.

I'm not running one, but four. Still, not a big deal. I thought I'd check it out their reporting tool which tells me:

BEAST attack -- Vulnerable INSECURE (more info)
Secure Renegotiation -- Not supported ACTION NEEDED (more info)
Insecure Renegotiation -- Supported INSECURE (more info)

That's fine and dandy. But each of the "more info" links goes to a blog posting that discusses the topic just a little bit, and only one of them provides enough information to fix it. Thankfully our sites aren't handling financial transactions of any kind, or I might have to actually locate a fix... how is everyone else fixing this (esp. the renegotiation vulnerability) if there's nothing available to remedy it except for disabling renegotiation?

I've been getting this since 2004.

There's an archive here to see if it helps you:

http://www.qualys.com/research/sans-at-risk/

Subscribing is here:

http://www.qualys.com/company/compref/

although I've been getting it since all you had to do was send an email.

I've been getting this since 2004.

There's an archive here to see if it helps you:

http://www.qualys.com/research/sans-at-risk/

Subscribing is here:

http://www.qualys.com/company/compref/

although I've been getting it since all you had to do was send an email.

Qualys provides a free BrowserCheck tool to look for insecure browser& plugin versions or configuration. While there is a windows plug-in available for deep scanning, basic scanning can be preformed with just javascript. Try it out at: https://browsercheck.qualys.com/

So, you got to install a plug-in to check if your other plug-ins are secure. Maybe the browsercheck plug-in isn't secure.

It didn't install a plugin for me. In fact, after seeing people complain here about the plugin I check the FAQs:
https://community.qualys.com/docs/DOC-1542#s1

It seems that only Windows users need a pluging. On my Kubuntu system it was all Javascript (I suppose, what else could it be?). So the answer to your "Why must I install an insecure plugin" question seems to be: "Because you are using Windows".

I went to the Browser Check link and was told that I have to enable Java and refresh the page. So to check my browsers security I first have to lower my current security settings? Now I see how they got their numbers.

posted it in the main thread already, but this is the source i have on it:

http://laws.qualys.com/2010/05/end-of-life-for-windows-xp-sp.html

My own company (world wide ~90000 employees) pushed SP3 only just a few months ago, and we are actually an IT-minded club

http://laws.qualys.com/2010/05/end-of-life-for-windows-xp-sp.html

That article states SP2 is still used on 50% of XP machines

I work for the PCI-certified Approved Scan Vendor (ASV) Qualys.

This is a timely article, as yesterday was the end of the quarter, and proof of PCI compliance was due. In addition, this is the first quarter that AMEX and VISA are actually fining customers if they do not meet compliance on time - starting at $5k USD per day!

As such, we have been extremely busy with the volume of customers who use us for PCI compliance. We even have a seperate service to handle this business, apart from our flagship vulnerability management product, QualysGuard. (Note: We're upgrading today, 3/31, so you will see an 'Under Construction' page for it).

My perspective on PCI compliance, from working with our customers on it, is that it is actually a crapload of work for companies to do. The standard is actually a pretty high bar. For example, a webserver that allows SSLv2 will fail you, or a VPN device that allows connections with regular DES.

It may not be a perfect standard (how do you deal with 0-day exploits that have no fix, but represent a serious vulnerability?), but it's a pretty good starting point, IMNSHO.

...something more professional.

Can anyone actually prove this one way or the other. Personally I doubt this is true... I bet most power users patch quickly, but closed/open source is not a factor.

I would love to see a study of patches vs user type. I know Qualys has done some work in this area. My guess is that mere mortals patch/update equally, or that windows people might actually patch more often (since they are root, windows update is pretty easy, and they been yelled at more often).

The biggest threat is that many scanners have a habit of crashing services which the developers have never encountered. Sadly, for the open source fans out there, Nessus is particularly bad with their QA and crashes all sorts of stuff even when the DoS tests are turned off. Of the commercial applications Qualysguard (www.qualys.com) does a great job of playing softly softly with the network while still detecting more than anything else out there (at least according to the size of their database). Don't bother considering anything else, other commercial scanners are less capable than nessus or qualys. But..... if you're worried that a security scan is going to cause adverse effects then you've clearly got security issues with your network. If a system dies under the load of a scan, or if some scan script triggers a DoS on your code then it's a sign that your developers and admins aren't doing their job correctly. Look upon it as a challenge, you should be saying 'Bring it on!'. If you're not confident that an automated security scan won't cause trouble with your system then you should be having nightmares about what a real hacker could do to your network.

My company recently purchased an SSL cert from verisign and recently received an email from http://www.qualys.com (in conj. with our purchase) to perform a web based security scan of internet facing machines, such as web servers. The results and demo reports appeared a bit better than our usual Nesus vulneravility scan, however, Qualsys is not free. Try these tools out, for web servers, they have done quite well for my end.

It shouldn't take much effort to pick up where PivX left off.

To make it even better, the known security vulnerabilities of other browsers could be added for comparison and quick review for those (mostly everyone) who don't have the time/inclination to scour the web looking for all the disparate info on browser insecurities...

...or perhaps this already exists & I'm not finding it?

For those who still use IE, you have can check your browser for security vulnerabilities here, http://browsercheck.qualys.com/, though I don't use IE & cannot vouch for the effectiveness of their scanning/detection.

So, who's gonna step into PivX's shoes?

Either You setup a secure linux box and nessus to get free scanning, or if you want the corporate/easy/expensive option you get qualys which scans for more vulnerabilities than anyone else and can do this from 1U server appliance, rather than the half rack that Foundstone has been trying to sell to people.
Never mind the whole legal problems that they have and the fact that their talented programmers keep jumping ship.
Foundstone have too many liabilities and not enough of a product for the cost.
I like nessus, but they do have a habit of crashing services and incorrectly identifying services, and it's GPL - although I hear that nessus is somewhat ironicly violating the GPL by blocking off parts of it's update site to known 'competitors' including foundstone, ISS and qualys.

QualysGuard has a bigger database than any of the competitors - More vulnerabilities than in Nessus and ISS combined - yet it doesn't make the top 75 list because it's more a service or appliance. It always seems to miss these lists since you can't buy it as a standalone software package.

Just in case there's a corporate CSO out there reading Slashdot.

I know one company which does this - Qualsys have this vulnerability scanning system which scans your computers for potential security threats, but to get it through most corporate firewalls tehy allow customers to use a special box on the inside of their firewall. This runs their scanner software and is locked down so that users can't see the software on it, but they provide a list of all the GPL components and will provide them in line with the spec. The boxes are basically useless unless you've signed up for their service so they're effectively rented, but, they make great efforts to comply with the GPL.

Try FreeScan from Qualys. Nice web based tool.

(In all fairness to them, they do provide source alongside the pre-compiled binaries, so the security-conscious can audit the code and recompile.)

This reminds me a lot of a rant or two by Rick Moen of SVLUG fame. The main problem is sysadmin inexperience. Granted, you can still trash your own files (and lose all your user data), but the system will be safe. So just run untrusted executables as a different, non-privileged user, if you must run them at all.

> It also installs a backdoor in the infected host,
> listening on UDP port 5503 or higher.
>
> An attacker could connect to this port via TCP and ...

According to qualys' actual release, an incoming UDP packet will trigger the compromised machine to initiate an outgoing TCP connection. Similar effect, but different net traffic.