Caporegime
I get the impression you're battling with the Intel PR machine here.
-
Competitor rules
Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.
Yet another Intel CPU security vulnerability!
- Thread starter Selekt0r
- Start date
I get the impression you're battling with the Intel PR machine here.
It's okay he's testing my belief and sticking to his guns. The thing is that I get the feeling that it's pointless anyway, as a 3800x with tight ram timings is just as fast as the 9900k. I guess AMD will be next for security if their market share increases. Intel are getting all the focus at the moment. Anyway the current intel security hole suck.
Caporegime
My £190 Ryzen 5 8700K / 9700K makes me happy, and i don't worry about what its not leaking to the net, Win win... that's all i care about
It's not though buddy, I've made my position clear and have invested in Zen in a big way. What you are getting here is not Intel apologists, it's a realistic summary of the feasibility of some of the attacks. It doesn't take away from the fact that their processors are unsecure and a bit crap. People are just pointing out that at this time, as in right now, it's not easy to exploit. It's clearly not just a bit of java script in a browser and you have all the secrets you need and to argue that it is shows significant holes in knowledge when it comes to the finer details of these exploits.
The zen architecture and specifically epyc is impressive from a security point of view and id be surprised if we see any major vulnerabilities in the immediate future regardless of market share. It's immediately clear to anybody in the industry who knows what they are talking about and those that don't. The problem here is that those who know what they are talking about at any sort of reasonable level are being targeted by the AMD machine when in reality this is nothing at all to do with AMD and has 0 bearing on AMD. Comments like "3800x with tight ram timings is just as fast as the 9900k" has 0 relevance in context of Intel security.
It's all about the stance of the reader, for me I run several DC's, I am a gamer, a programmer, and tech enthusiast. Yea I love making fun of the current Intel position as much as the next man but really the only thing relevant in here is how much performance hit, how bad is it, who should be worried and what can we do to mitigate. How AMD compare at this point is actually pretty irrelevant.
Caporegime
That's a pretty fair comment, i don't pretend to understand it which is why i read this thread much more than i participate.
Having said that i don't trust the agenda of a minority of others in here nearly as much as i trust yours.
This is just the beginning I am sure, we aren't done with these yet and until Intel pull their finger out and make something happen we will keep seeing threads exactly like this one and you can bet your bottom dollar that as time pushes on and people understand more and more the finer workings of the skylake arch and that sketchy looking management engine, that we might, in the not to distant future genuinely have a scenario where quite frankly the best thing to do is throw the intel server and chip in the bin. It is almost inevitable at this point, I'm just making my move early.
So far I cant fault my EPYC chips they are genuinely EPYC.
Last edited:
You really should re-read my post - spamming stuff like information about SUDO demonstrates you haven't understood how this attack works or what I said.
The attack relies on repeatedly invoking passwd over and over very fast so as to force it to leak information the attack can use to gain the encrypted password - what do you think happens in a real environment when you make multiple attempts to login with invalid credentials? so after awhile security measures kick in locking you out of being able to invoke passwd long before you've gathered enough information to piece together the encrypted password/hash. A factor that isn't mentioned in the whitepaper but important to understanding the application of the attack and my point being these kind of factors exist and need to be understood for the other variants of how you can use RIDL as well.
I am not dismissing this attack but like with the JS one you have to understand factors that are glossed over in the whitepaper to understand what the proof of concept is demonstrating and the important bits of the theory to understand their application - you can't use the RIDL passwd attack to steal a hash in most real scenarios - but neither should you be able even theoretically be able to leak credentials past the boundaries in that scenario which makes it potentially useful for a hands on attacker who can test a machine for other areas that might be weak to that kind of attack.
Last edited:
Caporegime
This is just the beginning I am sure, we aren't done with these yet and until Intel pull their finger out and make something happen we will keep seeing threads exactly like this one and you can bet your bottom dollar that as time pushes on and people understand more and more the finer workings of the skylake arch and that sketchy looking management engine, that we might, in the not to distant future genuinely have a scenario where quite frankly the best thing to do is throw the intel server and chip in the bin. It is almost inevitable at this point, I'm just making my move early.
Last thing i'll say on this because i don't want the thread to run off topic.
What i see in Intel is an infinitely impressive company, but not the leaders in their field as much as they proclaim, not since inventing X86 have i seen them do anything that moves the technology forward, they are also a very typical big corp, faceless, distant.
So take AMD, the face of the company are all engineers, awkward on stage, don't really know what they are doing there, they are not PR people, Dr Lisa Sue, Forrest Norrod, Mark Papermaster, Robert Hallock, these are the people who actually turn the cogs and some of them are also approachable, i have spoken with a couple of them through social media, they don't distance themselves from the public.
AMD's history, this is where a company of 11,000 quality engineers comes in.
Problem: The memory controler on the Motherboard is a bottleneck, move it to the CPU die.
Problem: One core having to do all the work is a bottleneck, create the worlds first multi-core X86 CPU.
Problem: DDR on GPU's is a bottleneck, Invent GDDR.
Problem: X86 its self is now the bottleneck, create AMD64 / X86_64 (64Bit PC, Intel tried to counter it but it wasn't as good, Intel now licence AMD64)
Problem: A CPU is good for serial execution but rubbish for parallel execution, create an architecture where X86 can run serial and parallel simultaneously (Heterogeneous System Architecture)
Problem: GDDR is now becoming the bottleneck, Invent HBM
Problem: DX11 is inefficient, Create a new API from the ground up that's much better, (Mantle, now Vulkan)
Problem: CPU die sizes are getting too big and expensive for high core count servers, create an architecture that can split the CPU into much smaller dies which can then be stuck together like Lego.
You don't sit and wonder what innovative new thing Intel are going to come up to solve a problem, they are not the problem solvers.
Intel are completely stagnant and the quality of their products from a technology point of view are outdated to be polite, i don't even think Intel these days are a true technology company, i liken them a lot to Nokia in their last few years, a once great innovative company that completely lost its way.
Last edited:
This is just the beginning I am sure, we aren't done with these yet and until Intel pull their finger out and make something happen we will keep seeing threads exactly like this one and you can bet your bottom dollar that as time pushes on and people understand more and more the finer workings of the skylake arch and that sketchy looking management engine, that we might, in the not to distant future genuinely have a scenario where quite frankly the best thing to do is throw the intel server and chip in the bin. It is almost inevitable at this point, I'm just making my move early.
As I said in my first post I would have severe reservations about hosting server like tasks on an Intel system these days - fortunately no longer my job - in the past I used to do this kind of thing for companies like for instance I did a few years doing the technical implementation and security behind the scenes at escapedturkey.com (GSP) in a kinder age where side-channel exploitation was something muttered about in dark corners and rarely a serious security concern for day to day operations.
Personally if I was still in that game I'd have stuck the Intel servers in the bin long ago - with multiple ways for users to login to the system with the potential to execute code (a lot of the control panels, etc. were based on webmin with heavy reliance on scripts which potentially could have been compromised as often they were involved in starting up executables with custom arguments, etc.) as well as clients being able to upload/manipulate executables or even having remote access there would just be too many potential areas of weakness in today's environment hosted on Intel. Albeit the standard shared servers clients could only upload datafiles with the executables locked down and those with more full control over their game server (for instance if they wanted to run unsupported game mods, etc.) generally being hardware isolated (though in some cases this was just a hypervisor).
EDIT: LOL this post I made once on the escapedturkey forums dated badly:
Last edited:
Exactly this. These security vulnerabilities are a concern in the right scenario. I don't think anyone in this thread is denying that or trying to gloss over the issue as part of some Intel PR stunt. I don't have a pro Intel agenda, I'm just pro truth. So I have to take issue when someone starts claiming that all home users with Intel processors have to disable HT otherwise their secrets will be stolen whilst browsing the web. My gaming PC does have an Intel CPU, but it doesn't have HT, so why would I care? Like some others in this thread I work in the IT industry and manage servers with a mix of Intel and AMD processors. Believe me, I'm no Intel fanboy after the extra work these vulnerabilities have created for me.
Last edited:
Your post is attacking your own straw man, no one will respond. I don't even have to write why. Your straw man is that the vulnerability has to be your concept of world world really. That's not how security works.
In security you don't wait until the world is full of attacks or wait and see. Your position is a load of complete unrealistic non-sense. Even so most ssh connections are not locked down after three tries because that would cause a £400 engineer visit every time someone got locked out. I know this because I am a network engineer (windows server, cisco CCNP R&S ccna security and electrical&electronic engineer). ssh normal only runs over out of band networks not accessible anywhere else but the Network Operations Center or teams that need access. Security people think of these things. So you stating that you can just add a lockout limit shows how little you really know.
Basically the advice of almost everyone with a clue is to turn HT off because its a security hole. Even home users are being forcibly patched as they become available. Even Google is turning off HT for EU's. RIDL cannot be patched and security is only as good as the weakest link. Proof of concept attacks exist. What more can be said. If you don't want to lessen that your problem. Just accept you have no online privacy and could get hacked. It's not going to happen to me, why should I worry about people who don't want to listen to experts?
Sure let's accept that proof of concepts are not full hacking tools. Even so you still turn off HT because one day they will be.
Last edited:
OK so tell me - in the real world can you just hammer passwd or an SSH connection with invalid credentials for 24 hours in a properly setup environment?
What relevance does SSH normally running over out of band networks have? you are just throwing things in that sound vaguely like they are related to muddy the waters. (the RIDL exploit against passwd/SSH works via say a VM or other secure enclave already running on the target system so it doesn't matter what kind of network infrastructure is used in that respect).
No a normal implementation would be something along the lines of after X number of tries throttle the connection so you have to wait say 15 minutes before trying again and after X number of tries after that blacklisting the connection. (Look up how something like fail2ban works - which if you are who you say you are you should be familiar with). Most enterprise type networks will also have a variety of other watchdog/sentinel software in place designed to identify odd patterns, brute force and denial of service type attacks and/or stop them happening in the first place.
Last edited:
Like I stated before ssh connection run over out of band networks. You can't connect to them from outside the out of band network. There have been ssh attacks before. If you cannot connect you cannot attack right? Your whole argument is ignorant. You are just slapping together anything you can think of. For network devices tacacs+ is used to authenticate logins and that will lock the account if to many failed logins happen. You can use radius in a multiple vendor environment. You then use Access control lists to block IP address outside the oob network from connecting to any network devices or servers in the oob network.
You have to protect within your network as well. You don't want people stealing information they should not have.
The stop EU's from connecting devices to the switch to attempt to get into the oob network, we can put ports into disabled vlan's, disabled ports or use qot1x so that users get moved into vlans that they should only be in (radius can do this on a windows server).
The ssl attack should be impossible to carry out from outside/inside the enterprise regardless because you have defense in depth.
Even so, many devices have a single global password for ssl access.
Last edited:
Um how on earth is that relevant to a RIDL attack that is designed to be used to exploit a system it is already running on? it is you who is just slapping anything together you can think of.
In cases where there is a higher level of isolation and VM instances can't just connect to the SSH connection of another VM instance that just further goes against your claims as it means in the real world mitigations are in place (and another omission from the whitepaper) that make the proof of concept an interest theory but not something that itself can be accomplished outside of that proof of concept.
Last edited:
Are you a child of something? I'm talking to a 13 year old right?Please god tell me you are not solely in charge of security there?
Now I'm confused. Are you now saying RIDL can't be used to attack such a system even with HT turned on? I think you've tied yourself in knots.
All that matters security wise is the RIDL attack exists. You then plan how to close the hole. You don't go, I need to win a forum debate about HT. So I will create sophistry about doing nothing. One of the attacks steals your location from your web browser while you at browsing using the Tor network (https://www.torproject.org/). In the right country, that's your life on the line .
Off course you are confused. They call it Defense in depth.
Defense in Depth (DiD) is an approach to cybersecurity in which a series of defensive mechanisms are layered in order to protect valuable data and information. If one mechanism fails, another steps up immediately to thwart an attack.
Defense in depth (also known as Castle Approach[1]) is an information assurance (IA) concept in which multiple layers of security controls (defense) are placed throughout an information technology (IT) system. Its intent is to provide redundancy in the event a security control fails or a vulnerability is exploited that can cover aspects of personnel, procedural, technical and physical security for the duration of the system's life cycle.
35 but if you want to start personal attacks then I can roll with the best of them. You are demonstrating in this thread that you don't seem to grasp the basic concepts and what is and isn't possible, your arguments are if anything pretty child like in your "straw man" rubbish... Your general understanding and ability to comprehend is poor and your retorts questionable at best. Ignorance is not an excuse "Security people like me think of these things." - Yet your demonstrating a very poor grasp of security.
Given what you have shared so far you wouldn't make my security or network teams... just saying.