Ledger to Discover HSM Vulnerability

HSM is an external device designed to store public and private keys used to generate digital signatures and to encrypt data, used by banks, exchanges, etc
10 June 2019   1018

A group of researchers from Ledger identified several vulnerabilities in the Hardware Security Module (HSM) devices, which can be used to extract keys or perform a remote attack to replace the firmware of an HSM device. The problem report is currently available only in French, the English-language report is scheduled to be published in August during the Blackhat USA 2019 conference. HSM is a specialized external device designed to store public and private keys used to generate digital signatures and to encrypt data.

HSM allows you to significantly increase protection, as it completely isolates keys from the system and applications, only by providing an API to perform basic cryptographic primitives implemented on the device side. Typically, HSM is used in areas where you need to provide the highest protection, for example, in banks, cryptocurrency exchanges, certification centers for checking and generating certificates and digital signatures.

The proposed attack methods allow an unauthenticated user to gain complete control over the contents of the HSM, including extracting all the cryptographic keys and administrative credentials stored on the device. The problems are caused by a buffer overflow in the internal PKCS # 11 command handler and an error in the implementation of the cryptographic protection of the firmware, which bypasses the firmware check using the PKCS # 1v1.5 digital signature and initiates loading the own firmware in the HSM.

The name of the manufacturer, the HSM devices of which have vulnerabilities, has not yet been disclosed, but it is argued that the problem devices are used by some large banks and cloud service providers. At the same time it is reported that information about the problems was previously sent to the manufacturer and it has already eliminated vulnerabilities in the fresh firmware update. Independent researchers suggest that the problem may be in the devices of the company Gemalto, which in May released an update to Sentinel LDK with the elimination of vulnerabilities, access to information about which is still closed.

Google to Propose to Develop Own Libc For LLVM

Development is caused by Google's unsatisfaction in the existing libc and it's planned to be phased, gradually increasing functionality
26 June 2019   32

One of the developers from Google raised on the LLVM mailing list the topic of developing a multi-platform standard C-library (Libc) within the framework of the LLVM project. For a number of reasons, Google is not satisfied with the current libc (glibc, musl) and the company is on its way to developing a new implementation, which is proposed to be developed as part of LLVM.

LLVM developments have recently been used as the basis for building Google's assembly tools. The main idea is that if Google has already begun to develop its libc, then why not immediately develop its system as part of LLVM, which already offers its standard library for C ++ (Libc ++), but does not have a similar standard library for C ( Libc).

Development is planned to be phased, gradually increasing functionality. The first options are proposed to be in the form of a layer between the application and the system libc, from which the unrealized features will be borrowed. After reaching a certain level of functionality, the new Libc can be used as a complete replacement for the system Libc. It is planned to start with the support of x86-64 architecture, Linux and static binding (dynamic loading, packaging, and additional architectures will be implemented in the second place).

The project is still at the initial stage of development, but the basic goals have already been defined:

  • Modularity and development in accordance with the philosophy of supplying a granular library, rather than a monolithic set;
  • Static binding support in modes with PIE (Position-independent executables) and without PIE. Providing CRT (C runtime) and PIE loader for statically linked executable files;
  • Support for most of the functions of the standard C library with POSIX add-ons and some system-specific extensions in demand in existing applications;
  • Careful attitude to vendor-specific extensions and adding them only when necessary. For support for third-party extensions, it is proposed to use the Clang and libc ++ projects approach;
  • Using exemplary practices in development using LLVM tools, such as applying sanitizer and fuzzing testing from the start.

Get more info at the developers thread.