Category: Uncategorized

IDA 6.9 released

~ hucktech ~ Leave a comment

https://www.hex-rays.com/products/decompiler/news.shtml#151221
https://www.hex-rays.com/products/ida/6.9/index.shtml

It has AArch64 support!

There’s another comment on Twitter from The Rootless Monster, wondering about UEFI TE support in the latest release, unclear if TE support has changed in 6.9:

https://twitter.com/osxreverser/status/679343362936315904

 

UEFI gets more IPMI 2.0 features

~ hucktech ~ Leave a comment

Daocheng Bu of Intel added new IPMI libraries to UEFI’s public EDK-I dev kit. Earlier, IPMI 2.0 definitions were added, now a library to support a generic PIMI submitt command has been added:

Update Ipmi2.0 definitions header file and MdeModulePkg.dsc
file for Ipmi libraries. Add Ipmi realted libraries to support
generic Ipmi submit command. Also add Ppi/Protocol definitions
that will be produced by Ipmi Peim and drivers.

  MdePkg: Update Ipmi2.0 definitions header file.
  MdeModulePkg: Add IpmiLib and Ppi/Protocol header file.
  MdeModulePkg: Add BaseIpmiLib Null Library Instance.
  MdeModulePkg: Add PeiIpmiLibIpmiPpi Library Instance.
  MdeModulePkg: Add DxeIpmiLibIpmiProtocol Library Instance.
  MdeModulePkg: Add SmmIpmiLibSmmIpmiProtocol Library Instance.
  MdeModulePkg: Update MdeModulePkg.dsc file for IpmiLib.

   18 files changed, 803 insertions(+), 135 deletions(-)

More info: see the patch on the edk2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

Android deprecates GCC, switch to Clang

~ hucktech ~ Leave a comment

From the Android NDK Changelog for NDK Build 2490520:

Clang:
    PSA: Everyone should be switching to Clang.
    Clang has been updated to 3.8svn (r243773, build 2481030).
        Note that this is now a nearly pure upstream clang.
        Also note that Clang packaged in the Windows 64 NDK is actually 32-bit.
    Support for emulated TLS.
        __thread is now supported by the compiler by emulating ELF TLS with pthread thread-specific data.
        C++11 thread_local will work in some cases, but will not work for data with non-trivial destructors except when running on Marshmallow (android-23) or newer because those cases require support from libc.
        Does not yet work with Aarch64 when TLS variables are accessed from a shared library.

GCC:
    GCC in the NDK is now deprecated.
        Time to start using Clang if you haven’t already. If you have problems with Clang, please file bugs!
        The NDK will not be upgrading to 5.x, nor will we be accepting non-critical backports.
        Maintenance for miscompiles and internal compiler errors in 4.9 will be handled on a case by case basis.
    GCC 4.8 has been removed. All targets now use GCC 4.9.

https://android.googlesource.com/platform/ndk.git/+/master/CHANGELOG.md

 

New UEFI-patched GRUB Legacy

~ hucktech ~ Leave a comment

There’s a new GRUB Legacy build on Github, which has some UEFI patches, called grub0.97-patched. The forker has a strong opinion towards GRUB 2… 🙂

 

“A fork of GRUB 0.97 (aka Legacy), included several patches for UEFI, RAID, GPT, … I created this repo to archive the last version of GRUB Legacy and their community-made patches that were scattered all over the Internet. GRUB development team has deleted the repo of GRUB Legacy, citing that GRUB 2 is the future. In fact, their future is shit.”

https://github.com/annguyenfoss/grub0.97-patched

https://github.com/annguyenfoss/grub0.97-patched/commits/master

 

Nikolaj’s UEFI SecureBoot tutorial

~ hucktech ~ Leave a comment

CodeRush has a new tutorial on UEFI SecureBoot:
Taming UEFI SecureBoot tutorial

[…] let’s talk about how to make a UEFI SecureBoot not work for the benefit of Microsoft, as it is often set at default, and for the good of us. If you’re wondering how to generate their own your own keys for SecureBoot how to install them instead of the standard (or with them), you sign your favorite EFI-boot, how to prevent loading of unsigned or signed other people’s key code, it looks like the interface to configure SecureBoot at AMI, Insyde and Phoenix, […]

It is in Russian, use a translation tool if you can’t read Russian (like me). The article has multiple examples and screenshots of multiple UEFI implementations, and includes some UEFI links at the end that I’ve never seen before, exciting!

http://habrahabr.ru/post/273497/It’s/

http://translate.google.com/translate?hl=en&sl=ru&tl=en&u=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F273497%2FIt%27s%2F&sandbox=1

Guido Stepken on Linux UEFI TPM 2.0 backdoors

~ hucktech ~ Leave a comment

https://twitter.com/SecNewsBot/status/677681956176404480

Guido Stepken has a Google+ post from September (which I didn’t notice back then), and the SecNewsBot on Twitter just posted this like it is news. Well, it is news to me. 😦

Linux UEFI TPM 2.0 security impacts:
The “security chain” begins with one or more TPM 2.0 “Endorsement Keys” (EK), that are stored on the motherboard and that cannot be overwritten without “allowance” by either the owner (hardware manufacturer) or somebody, that is “higher” in key hierarchy, such as Microsoft or U.S. government authorities. Key Exchange Keys (KEK) establish a trust relationship between the operating system and the platform firmware. Each operating system (and potentially each 3rd party application, that needs to communicate with platform firmware) enrolls a public key (KEKpub) into the platform firmware. When your hardware comes “Windows Certified”, the “Endorsement Key” already is initialized, is signed by Microsoft and U.S. authorities. “Windows certified” here automatically means “NSA backdoor” included and activated in all encryption modules. Hardware encryption on newer INTEL Xeon machines, at boot, load those key rings from UEFI tables into processor buffer. From then on, the CPU hardware encrypts everything with Microsoft and U.S. authorities keys being enclosed in the key ring, independent of used operating system! […]

Full article:

https://plus.google.com/+GuidoStepken/posts/XZsgDcuairt

VMware security update

~ hucktech ~ Leave a comment

http://www.vmware.com/security/advisories/VMSA-2015-0009.html

Advisory ID:     VMSA-2015-0009
Synopsis:     VMware product updates address a critical deserialization vulnerability
Updated on:     2015-12-18 (Initial Advisory)
CVE numbers:     CVE-2015-6934

VMware product updates address a critical deserialization vulnerability in vRealize Orchestrator 6.x and vCenter Orchestrator 5.x. A deserialization vulnerability involving Apache Commons-collections and a specially constructed chain of classes exists. Successful exploitation could result in remote code execution, with the permissions of the application using the Commons-collections library. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the identifier CVE-2015-6934 to this issue.

Juniper ScreenOS vulnerability, continued

~ hucktech ~ Leave a comment

This is another reason why the FCC should not ban open source devices (WiFi or other ones), closed-source products enable hiding attacker malware and government backdoors…

https://twitter.com/hdmoore/status/677951372151627776

https://github.com/hdm/juniper-cve-2015-7755

http://recode.net/2015/12/18/who-hid-a-secret-back-door-in-junipers-security-gear/

http://www.wired.com/2015/12/juniper-networks-hidden-backdoors-show-the-risk-of-government-backdoors/

BareDroid: Large-Scale Analysis of Android Apps on Real Devices

~ hucktech ~ Leave a comment

To protect Android users, researchers have been analyzing unknown, potentially-malicious applications by using systems based on emulators, such as the Google’s Bouncer and Andrubis. Emulators are the go-to choice because of their convenience: they can scale horizontally over multiple hosts, and can be reverted to a known, clean state in a matter of seconds. Emulators, however, are fundamentally different from real devices, and previous research has shown how it is possible to automatically develop heuristics to identify an emulated environment, ranging from simple flag checks and unrealistic sensor input, to fingerprinting the hypervisor’s handling of basic blocks of instructions. Aware of this aspect, malware authors are starting to exploit this fundamental weakness to evade current detection systems. Unfortunately, analyzing apps directly on bare metal at scale has been so far unfeasible, because the time to restore a device to a clean snapshot is prohibitive: with the same budget, one can analyze an order of magnitude less apps on a physical device than on an emulator. In this paper, we propose BareDroid, a system that makes bare-metal analysis of Android apps feasible by quickly restoring real devices to a clean snapshot. We show how BareDroid is not detected as an emulated analysis environment by emulator-aware malware or by heuristics from prior research, allowing BareDroid to observe more potentially malicious activity generated by apps. Moreover, we provide a cost analysis, which shows that replacing emulators with BareDroid requires a financial investment of less than twice the cost of the servers that would be running the emulators. Finally, we release BareDroid as an open source project, in the hope it can be useful to other researchers to strengthen their analysis systems.

https://dl.acm.org/citation.cfm?id=2818036
https://github.com/ucsb-seclab/baredroid

F-Secure’s Sandboxed Execution Environment project

~ hucktech ~ Leave a comment

Sandboxed Execution Environment (SEE) is a framework for building test automation in secured Environments. The Sandboxes, provided via libvirt, are customizable allowing high degree of flexibility. Different type of Hypervisors (Qemu, VirtualBox, LXC) can be employed to run the Test Environments. Plugins can be added to a Test Environment which provides an Event mechanism synchronisation for their interaction. Users can enable and configure the plugins through a JSON configuration file. SEE is for automating tests against unknown, dangerous or unstable software tracking its activity during the execution. SEE is well suited for building modular test platforms or managing executable code with a good degree of isolation. SEE allows to write sandboxed tests both for quick prototyping and for running on production environment. […]

More info:
https://github.com/F-Secure/see
https://pypi.python.org/pypi/python-see
http://pythonhosted.org/python-see
http://libvirt.org

lowRISC untethered release

~ hucktech ~ Leave a comment

Today the lowRISC team announced the “Untethered lowRISC release”:

Over the past several months, we’ve been working to provide a standalone or ‘untethered’ SoC. Cores in the original Rocket chip rely on communicating with a companion processor via the host-target interface (HTIF) to access peripherals and I/O. This release removes this requirement, adding an I/O bus and instantiating FPGA peripherals. The accompanying tutorial, written by Wei Song, describes how to build this code release and explains the underlying structural changes. We support both the Xilinx KC705 and the lower-priced Nexys4 DDR development boards. We would gladly welcome assistance in supporting other boards. […]

Full announcement:

http://www.lowrisc.org/blog/2015/12/untethered-lowrisc-release/
http://www.lowrisc.org/docs/untether-v0.2/
http://www.lowrisc.org/docs/untether-v0.2/release/
https://github.com/lowRISC/lowrisc-chip/
http://lowrisc.org/

Juniper’s ConsoleOS vulnerable

~ hucktech ~ Leave a comment

http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554

Request to college professors

~ hucktech ~ Leave a comment

There are many Verified/Secure/Trusted/Measured boot implementations and VMM/HW/OS combinations. Most have similar use of crypto, with multiple keys. Some work with a TPM, or under a TEE. Some solutions incorporate multiple (eg, I think current Windows supports UEFI Secure Boot and TCG Trusted Boot and Intel TXT Measured Boot together), I am still unclear how to get Linux to integrate in a similar way.

A few people have asked me which firmware solution is more secure. I don’t know the answer.

I wish that some university grad student would do a comparison of the crypto used in the various solutions. A student who is focusing on hardware, software, embedded systems, and cryptography would be ideal. 🙂

I think this might be too much of a request for a tech review site, like Toms Hardware or Consumer Reports. Perhaps NIST, when they next update their BIOS guidance, could give some help in this area? It would be nice if the UEFI, coreboot, U-Boot, and other projects had some detailed comparisons of their alternatives/competitors, as members of these teams are likely to be the only people who know the right answers offhand, without doing more research. Perhaps a Comparison_of_Firmware_Security_Technologies page on Wikipedia?

This data would not only be useful for helping the weaker firmware technologies improve themselves, but it’d help security-minded consumers make better product choices, and help OEMs/IBVs build more secure systems.

If you know of a grad student who fits the bill, or a professor who works in this area, please forward this request to them. Thank you very much!

LUV-live 2.0-RC4 released

~ hucktech ~ Leave a comment

Ricardo Neri of Intel announced Linux UEFI Validation (LUV) v2.0-rc4 release, with lots of changes, new versions of CHIPSEC, BITS, FWTS, and multiple UEFI improvements in LUV. IMO, one of the most important features it that LUV-live’s CHIPSEC should properly log results now! Excerpts from Ricardo’s announcement:

This release touches many areas. Here are some highlights:

Naresh Bhat implemented changes to build from Linus’ tree when building LUV for ARM. While doing this, he got rid of the leg-kernel recipe. Now the kernel is built from linux-yocto-efi-test for all architectures. Also, he took the opportunity to remove some of the LUV-specific changes we had in the meta layer (i.e., our genericarmv8 machine). It always good to restrict ourselves to the meta-luv layer, unless we plan to upstream to the Yocto Project. Now LUV for aarch64 is built using qemuarm64.

It was reported that CHIPSEC was not running correctly in LUV due to missing configuration files and Python modules. This release includes a major rework of CHIPSEC integration into LUV. It ran correctly on all the systems in which we tested. Also, we bumped to v1.2.2; the CHIPSEC latest release.

This release includes new functionality to build BITS from its source rather than just deploying its binaries. BITS is a challenging piece of software when it comes to integration into a bitbake recipe. The build process was broken into several steps. This work help for future work to customize BITS for other CPU architectures and netboot.

The UEFI specification v2.5 includes a Properties Table for the memory map. Under this feature, it is possible to split into separate memory sections the code and data regions of the PE/COFF image. Unfortunately, kernels previous to v4.3 crash if this features is enabled. We have backported a fix pushed to Linux v4.3. We will be bumping the kernel for x86 to 4.3 in our next release.

The EFI stub feature in the kernel allows to run the kernel as an EFI application. Also, it allows the kernel to parse the memory map directly from the firmware rather than taking the map from the bootloader. This is clearly advantageous in case of bugs in the bootloader.

Now that LUV support storing the results of multiple bots, it may happen that disk runs out of space. Gayatri Kammela made updates to increase the size of the results partition and issue a warning when available space runs below 2MB.

Finally, keeping up with the latest changes in the Yocto Project has paid off handsomely. This release is based on Jethro, the latest version of the Yocto Project. Rebasing to this new version as done with very little effort. In the LUV tree you can find the jethro and jethro-next branches; the bases of this release. The fido and fido-next branches are still maintained.

We have bumped the following test suite versions:

 *FTWS is now V15.12.00
 *CHIPSEC is now v1.2.2
 *BITS is 2005

Time to update your LUV-live images! It is a Release Candidate, so please help the LUV team by testing it out and pointing out any issues on the LUV mailing list. This version of CHIPSEC includes VMM tests, so time to test LUV-luv in your virtual machines, not just on bare-metal boxes.

Many people contributed to this release, including: Ricardo Neri, Naresh Bhat, Darren Bilby, Megha Dey, Gayatri Kammela, John Loucaides, Sai Praneeth Prakhya, and Thiebaud Weksteen. It was nice to see the LUV and CHIPSEC teams work together in this release!

More information:
https://lists.01.org/pipermail/luv/2015-December/000745.html
https://download.01.org/linux-uefi-validation/v2.0/luv-live-v2.0-rc4.tar.bz2
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc

https://01.org/linux-uefi-validation/

FDBG: AMD64 UEFI debugger

~ hucktech ~ Leave a comment

While searching for information about FASM for that last blog post, I also noticed this:

http://fdbg.x86asm.net/

“fdbg for AMD64 is assembler level debugger for user-mode (ring3) binary applications, running in long mode (64-bit) – Windows and Linux versions. Version for UEFI x64 is also available.

Supported platforms:

  • Windows XP x64, Windows 2003 server x64, Vista x64, Windows 2008 server x64, Windows 7 x64
  • Linux x64
  • UEFI x64

Windows Version is GUI based.

Linux version is command line based (console) and doesn’t need any library to run so it doesn’t matter what Linux distribution you use.

UEFI version is command line based.

fdbg project was started to help in debugging programs written in assembler to everybody who feels the power of assembler

 

  • it is written in Flat Assembler and source files are included
  • its syntax is similar to FASM
  • it supports debug symbols and you can find some tricks in included help how to debug without symbols
  • it is suitable for everybody who tries to create his/her first program written in assembler
  • it has some features and power for experienced users too
  • it is very small

“

 

I haven’t tried it yet,  but this looks interesting…

UEFI programming in Flat Assembler (FASM)

~ hucktech ~ Leave a comment

FASM is the Flat Assembler. There’s a new Github project with some FASM-based assembly hello-world samples for UEFI. UEFI’s EDK-II generall prefers C over assembly, and has some code to help replace the need for assembly: I have some notes on that somewhere, I was going to write a blog on that someday. And I thought that EDK-II prefers NASM as their assembler, so this FASM-based, Intel 32-bit assembly-based UEFI sample code is interesting. The x86asm.net article on UEFI programming also has examples of FASM-based UEFI programming.

https://github.com/eszkadev/UEFI-32bit-asm-examples

http://flatassembler.net/

http://x86asm.net/articles/uefi-programming-first-steps/