Hacker News new | past | comments | ask | show | jobs | submit login
Huawei HKSP Introduces Trivially Exploitable Vulnerability in the Linux Kernel (grsecurity.net)
102 points by phoe-krk on May 10, 2020 | hide | past | favorite | 22 comments



This sort of stuff was pretty common in the early Android days. Most root exploits were just clever attacks on the startup scripts and that continued for some time until the manufacturers finally wised up. HTC was particularly bad here.

I wouldn't attribute it to malice - just engineers without the right time and/or training.


This is explicitly security oriented code. The release notes indicate a high awareness of security issues and discuss some advanced topics and items its trying to mitigate.... and then the code has a way of leaking kernel memory. Do you really doubt an engineer (or potentially team of engineers) working in security could not see what was outlined in the article? Its suspect at least


C is absurdly easy to screw up like this. You need a lot of focused engineers, complete institutional focus on proactively catching things like this, and robust tooling to even have a hope of fixing all the low hanging security issues consistently. I don't find it hard to believe that Huawei missed one or all of those for at least long enough to make a patch.


I have looked at the patch, this is a huge patch file that includes lots of changes, this is not a patch that will ever be reviewed as it's not the standard that is expected from kernel developers: small patches that do specific things.

My guess that it comes from a person who is posting a patch for the first time to the mailing list.

attributing this patch to Huawei doesn't make sense, and if they really did want to introduce a backdoor I'll only assume that they would have prepared much better patches.

these kind of one time submissions are most likely to be ignored in the mailing list..

I think it only got attention because someone saw Huawei in the headline.


As a long time C developer, I'd say this looks like something I would have written in my early days. While I admit that Huawei is not above trying to put a backdoor in the kernel, but Grsecurity also has a history of blowing things out of proportion.


I have no knowledge of how the integrity of the Linux kernel is protected. So a small bit of background context would be nice. The article says this is a patch set. I assume this gets reviewed before it’s allowed into the kernel. I’m assuming the exploits were found before the patch was excepted. I can see a frustration in having to review really bad code.


No, this code wasn't proposed for inclusion in the Linux kernel. To do that, someone would have to send an email to the Linux kernel mailing list that says what the changes are for, who wrote them, etc. This is probably just something that Huawei wrote for their own custom kernel for their phones or something.


Is the only evidence that this has anything to do with Huawei is that the github account has listed Huawei somewhere on its profile?


So those is not used anywhere yet?

It's good GRS tries to raise awareness, but this could very well be an WIP or just some intern fooling around with Linux.


ELI5?


Is this purely careless programming, or genuinely diabolical to use in conjunction with something else to allow for more "interesting" things later?

Never attribute to malice...stupidity. However, I'm guessing since it is Huawei, it will always (deservedly?) be suspect as malice first?


Didn't the UK last year rip into Huawei after reviewing the networking software, finding something like 18 different versions of OpenSSL inside of it with various vulnerabilities. At some point, continuing a trend of stupidity should be considered malice.


Huawei promised to fix these horrible security issues after a code review in 2012 and the establishment of the HCSEC oversight board in 2014, yet HCSEC found Huawei had not fixed the issues found in 2012 in their 2018 report, at which point Huawei promised to spend $2 billion to improve code security.

IIRC the 2019 report from HCSEC outlined the same bugs had yet to be fixed. I think Huawei doesn't want to fix bugs in products they aren't currently selling (in part based on Nortel code that has been patched over the last decade with new features), thus the lies and lack of investment.

More reading: https://www.fiercewireless.com/wireless/uk-says-huawei-equip... and https://aragonresearch.com/cyber-war-flashback-remembering-t...


A less generous interpretation would be that Huawei cannot fix the code since they were the not the ones who wrote it on the first place.


I would put money on careless/unskilled programming over diabolical. For diabolical code, you would want something that could withstand a few levels of code review.


Why not both? Pepper the code with easy to find (and use) vulnerabilities and also a few harder to find. It's win win for those who are trying to inject the exploits, as if the obvious stuff can be chalked down to incompetence, then the subtle ones can surely be - so in a way its a smart method of shielding the nefarious act.


Yeah sadly this just looks like typical work not uncommon in huge tech corporations with pretty broken development and management pipelines.


it just looks like awful code which isn't really out of the ordinary for a lot of stuff I've seen from Huawei.

Other than that, attributing malice to someone just because it's a Chinese company is probably inappropriate.


Huawei has a history of stealing from other companies, regardless of it being a Chinese company.


You are the first person in the thread to bring up the fact that they are Chinese.


because it's the obvious subtext. Every time Huawei or Tiktok come up it's the same amount of accusations.


Facebook and Google probably feel the same way every time privacy conversations come up. Too bad. Walks like a duck, sounds like a duck, must be a duck. Don't care what country a company is from, if you keep doing the same thing over and over again, I'm going to have this opinion.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: