Vulnerability Research
May 24, 2020
By Ilya Khivrich

What Can Be Learned from the Recent HKSP Vulnerability

A recent publication reviewed candidate code that appeared to be a part of Huawei’s kernel hardening project. The code included what seems to be an easily exploitable stack overflow vulnerability.

According to the quoted response from Huawei, the code is not a part of any of their products, but we believe this story highlights a few key points that are worth reiterating:

  1. Code quality can be uneven across the codebase. Even highly experienced developer groups that directly deal with software security may introduce very simple and easily exploitable bugs. A procedure must be put in place that requires a complete examination and security assessment of the full product.
  2. All proprietary components need to be covered in this testing protocol, regardless of the stated categories, be it a kernel module like the one discussed above or interpreted code.
  3. All parts of the software need to be tested independently for security, even components that are provided in a compiled form by an external vendor. If such testing is impossible, these components should not be used since the developer groups cannot reliably assume that the provided code is secure.
  4. While some modern OS exploits rely on complex logical bugs which require substantial effort to locate and trigger, simple mistakes are not a thing of the past and present a very real concern, which in this case is easily preventable.
  5. Additional code layers, especially security layers, could increase the attack surface and should be reviewed with extra care.
  6. One important aspect of defensive programming is to avoid running code with permissions that are more tolerant than necessary, as happened in this case. Compliance with this principle also needs to be verified for the full product configuration.

At VDOO, we use a holistic approach to analyzing device security and to discovering zero-day flaws, using only the binary code. Our approach enables us to scan all proprietary components in the context of the final device image. We use several techniques for vulnerability detection, uncovering simple cases like the one discussed above, as well as more complex ones.

As always with security-related incidents, more details are sure to follow. We feel the points above are general and are in accordance with the information that has already been provided in this case. We will be keeping an eye out for updates and respond accordingly.

Please feel free to contact us if you have any questions or comments

Share this post

You may also like