HP Printers expose anon FTP

https://twitter.com/SteveD3/status/691934387357782017

Exposed HP LaserJet printers offer Anonymous FTP to the public

Networked HP LaserJet printers, which have been made available to the public by the organizations hosting them, offer potential attackers a ready-made Anonymous FTP server. At present, there are thousands of these devices online. The exposed printers were the focus of a new blog post by Chris Vickery. Vickery has previously worked with Salted Hash on a number of stories – including database leaks that exposed class records at SNHU, 3.3 million Hello Kitty fans, 191 million voter records, and an additional 18 million voter records with targeted data. […]

Full article:
https://mackeeper.com/blog/post/185-spilling-the-beans
http://www.csoonline.com/article/3026184/security/exposed-hp-laserjet-printers-offer-anonymous-ftp-to-the-public.html

reversing Google Nest devices

Kamil Domański has an article on Google Nest-flavored IoT reversing:

In the buzzword-powered world of IoT there doesn’t really seem to be as much innovation as some would have you think. The hundredth “smart” camera, door lock or lamp don’t really disrupt much, yet some players in this space seem to be getting far ahead of the others. A notable player in this space is Nest Labs who after their acquisition by Google rose to be one of the most prominent brand names in this space, now a subsidy of Alphabet. Here at Protonet we consider owning and having access to your own data as one of our core values – thus as much as we admire Alphabet’s tech, we’re sceptical about it’s cloud only approach to smart home products. It’s not much of a surprise then that we picked Nest products for our research efforts when looking into integration of different kinds of smart devices. […]

Full article: here (WordPress doesn’t like Tumblr.com URLs, refuses to show them.)

medical device firmware vulnerabilities at Usenix Enigma

The Register has an article on Usenix Enigma security conference, which includes discussion on medical device firmware security:

Terrible infections, bad practices, unclean kit – welcome to hospital IT
Medicine is world’s worst industry for data security, it seems

[…] Therein lies the problem, he said, in that the lead time for medical devices is so long that they are outdated in today’s security terms. He showed off a pacemaker that had a debug routine that could interrupt a heartbeat and was open to anyone. In some cases, medical devices themselves were a point of infection. One device manufacturer shipped out a malware-infected firmware update that contained 38 Trojans, which then spread throughout hospitals. […]

Full article:
http://www.theregister.co.uk/2016/01/25/the_worst_industry_for_keeping_it_systems_clean_medicine/

Docker acquires MirageOS

Docker buys Unikernel Systems

Docker has purchased the Unikernel Systems, a Cambridge, U.K. start-up specializing in unikernel development, Docker announced Thursday. The purchase will help Docker expand the range of virtualization technologies if offers the enterprise can use, in effect turning Docker into a platform for running a wide range of workloads, not just container-based workloads. […]

Full story:
http://thenewstack.io/docker-buys-unikernel-systems-plans-bring-unikernels-data-center/

https://mirage.io/
https://github.com/mirage/mirage

Using UEFI_boot_script_expl on Lenovos

Dmytro “Cr4sh” Oleksiuk has a conversation on Twitter about using using his CHIPSEC-based exploit module against Lenovo models, noting some firmware vulnerabilities in Lenovo x220/x230 laptops.

Here are 5 tweets, let’s see how the non-deterministic WordPress.com rendering software will show them:
https://twitter.com/d_olex/status/6916255973326315
https://twitter.com/d_olex/status/69162603603585024252

It is nice to hear “The most recent ones looks not vulnerable.” Maybe the Lenovo QA team is improving? 🙂 Looking forward to more research on this, more than just a few Tweets, his research is usually very verbose! Also, he has updated the readme on his update script today:

https://github.com/Cr4sh/UEFI_boot_script_expl

Toshiba to exit semiconductor manufacturing, except for NAND flash

[…] Toshiba has firmed up plans to unload a large portion of its semiconductor-manufacturing operations as part of sweeping reforms to improve profitability in the wake of an accounting scandal. The Japanese company plans to keep NAND flash memory operations, its biggest profit source and a field where its market share is second only to Samsung Electronics. Product lines up for sale include analog chips, LSI chips, microcontrollers and power-saving semiconductors. Applications include cars, industrial machinery, home electronics and housing construction equipment. […]

http://www.eetimes.com/document.asp?doc_id=1328763&_mc=RSS_EET_EDT

http://asia.nikkei.com/Business/Deals/Toshiba-to-whittle-down-chipmaking-ops

I wonder if there are any Toshiba chips for sale that might be useful to acquire for an Open Hardware venture?

reversing ARM1 conditionals

Conditional instructions in the ARM1 processor, reverse engineered
By carefully examining the layout of the ARM1 processor, it can be reverse engineered. This article describes the interesting circuit used for conditional instructions: this circuit is marked in red on the die photo below. Unlike most processors, the ARM executes every instruction conditionally. Each instruction specifies a condition and is only executed if the condition is satisfied. For every instruction, the condition circuit reads the condition from the instruction register (blue), evaluates the condition flags (purple), and informs the control logic (yellow) if the instruction should be executed or skipped. […]

Full post:
http://www.righto.com/2016/01/conditional-instructions-in-arm1.html

Zero perms to TrustZone: Android mediaserver CVEs discussion

https://pbs.twimg.com/media/CZgC2lkUEAA16RP.png:large

Android privilege escalation to mediaserver from zero permissions (CVE-2014-7920 + CVE-2014-7921)

In this blog post we’ll go over two vulnerabilities I discovered which, when combined, enable arbitrary code execution within the “mediaserver” process from any context, requiring no permissions whatsoever. How bad is it? The first vulnerability (CVE-2014-7921) was present in all Android version from 4.0.3 onwards. The second vulnerability (CVE-2014-7920) was present in all Android versions from 2.2 (!). Also, these vulnerabilities are not vendor specific and were present in all Android devices. Since the first vulnerability is only needed to bypass ASLR, and ASLR is only present (in a meaningful form) from Android 4.1 onwards, this means that these vulnerabilities allow code execution within “mediaserver” on any Android device starting from version 2.2. Although I reported both vulnerabilities in mid October 2014, they were unfortunately only fixed much later (see “Timeline” for full description, below) – in Android version 5.1!  This means that there are many devices out there which are still vulnerable to these issues, so please take care. You can find the actual patches here. The patches were pushed to AOSP five months after the vulnerabilities were reported. That said, the Android security team was very pleasant to work with, and with other vulnerabilities I reported later on, were much more responsive and managed to solve the issues within a shorter time-frame.
[…]

Full post:
http://bits-please.blogspot.com/2016/01/android-privilege-escalation-to.html

Sigh, it seem harder to track ARM firmware bugs, since they’re often hidden in the description of an app bug. And SCAP has no firmware OVAL definitions for CVEs to mention things like TrustZone. 😦

Intel Haswell GPU reversing

Joshua Barczak has a new blog post on reversing an Intel Haswell GPU, and has sample code on Github.

[…] Why Did I Go To All This Trouble? There are a couple of reasons why this is more than just a pointless exercise in reverse engineering. This hardware contains a lot of goodies that the graphics APIs simply do not expose, and I’m wondering if I can exploit any of them to demonstrate cool stuff. I obviously can’t do anything in a shipping product, but perhaps we’ll find ways of using the hardware that aren’t anticipated by current APIs and programming models. There is a lot of unexposed functionality in this architecture. You can send messages back and forth between threads. Threads can spawn child threads and read/write their register files using message passing. I dont know whether all the right bits are set by the GL driver to enable this, but if it works, it might be fun to experiment with. You can mix SIMD modes. Use SIMD4 instructions in one cycle and SIMD8/SIMD16 in another. You can use swizzles or register movs to do all sorts of cross-lane communication at very little cost. You can do warp-level programming, where each thread is 1 16-wide instruction stream instead of 16 1-wide streams. You can switch modes multiple times within the same thread if you like. As some of my Intel friends like to point out, on this hardware, every thread has 4KB of register space. The register file in total is roughly the size of the cache. There’s no “use fewer registers to boost occupancy”, the occupancy is just there. There is also GPR indexing, and unlike on other architectures it is actually potentially useful. Hardware threads can implement small fixed-size data structures entirely in their register files without it totally sucking. […]

Full post:
http://www.joshbarczak.com/blog/?p=1028
https://github.com/jbarczak/HAXWell
https://onedrive.live.com/view.aspx?resid=EBE7DEDA70D06DA0!107&app=PowerPoint&authkey=!AD-O3oq3Ung7pzk
https://01.org/linuxgraphics/documentation

Fast Boot, instead of UEFI Secure Boot

There may be some situations where Secure Boot is not useful, and Fast Boot is an alternative, which is fast but NOT SECURE. Here’s a quick summary by Nikolaj Schleg (aka CodeRush) of what is needed to disable Secure Boot and enable Fast Boot with use on Windows systems:

The best way to decrease boot time is to switch to UEFI boot, disable CSM, enable FastBoot and disable SecureBoot, because it takes some time to check a signature of your bootloader, and it will be checked on every boot.
If you remove all SecureBoot keys, the SecureBoot will switch into so called “Setup Mode”, where you can add your own keys without having a private parts of older ones (that are only available to Microsoft and ASUS, in your case). AMI-based UEFIs have a “standard” keys in default map, so don’t worry about losing the keys – you can easily restore them from Security->SecureBoot Settings setup page.
What you need to do:
1. Disable CSM.
2. Enable FastBoot.
3. Enable (better protection from bootkits, a bit slower boot time) or disable (a bit faster boot time, the same security level you have now with CSM) SecureBoot.
4. Don’t touch the keys, they are fine by default.
5. Reinstall Windows in UEFI mode.

 

Full post:
http://www.win-raid.com/t1495f13-UEFI-clearing-secure-boot-keys.html

There’s another guide for Windows 8.x here:
http://answers.microsoft.com/en-us/windows/forum/windows_8-performance/windows-8-can-not-stop-fast-boot/239e56e7-649d-4110-af4c-6fe9c3340530?auth=1

More on disabling Secure Boot keys:

Nikolaj’s UEFI SecureBoot tutorial

More on disabling Secure Boot:
https://technet.microsoft.com/en-us/library/dn481258.aspx

And for a bit of contrasting — yet still informative — advice, here’s how to disable Fast Boot:
http://support.fixmestick.com/hc/en-us/articles/200578596-Disabling-Fast-Boot-on-Windows-8-8-1-and-10

Some more on Fast Boot and Windows:
https://blogs.msdn.microsoft.com/b8/2011/09/08/delivering-fast-boot-times-in-windows-8/
https://msdn.microsoft.com/en-us/library/ms858380.aspx
https://blogs.msdn.microsoft.com/b8/2012/05/22/designing-for-pcs-that-boot-faster-than-ever-before/
https://msdn.microsoft.com/en-us/library/windows/hardware/jj835779%28v=vs.85%29.aspx

Car hackers take note at the use of Fast Boot (instead of Secure Boot) in Windows Automotive stack, in above MSDN docs. Yikes.

 

AArch64 Xen gets Dom0 ACPI support

Shannon Zhao of Huawei submitted a 17-part patch to the Linux-ARM-kernel, Linux-EFI, Linux-Kernel, and Xen-devel lists, which adds ACPI support for Xen Dom0 on AArch64 systems.

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from [1]. The corresponding Xen patches can be fetched from [2].

  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
  FDT: Add a helper to get specified name subnode
  Xen: EFI: Parse DT parameters for Xen specific UEFI

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] http://git.linaro.org/people/shannon.zhao/xen.git  ACPI_XEN_ARM_V3
http://vger.kernel.org/majordomo-info.html

AArch64 gets ACPI NUMA support

Hanjun Guo of Huawei submitted a 12-part patch to the Linux-ACPI, Linux-ARM-Kernel, and Linux-Kernel lists, which adds ACPU NUMA (Non-Uniform Memory Access) support for AArch64 systems.

Based on Ganapat’s v9 dt based NUMA patch set [1] for ARM64, this patch set introduce the ACPI based configuration to provide NUMA information. ACPI 5.1 already introduced NUMA support for ARM64, which can get the NUMA domain information from SRAT and SLIT table, so parse those two tables to get mappings from cpu/mem to numa node configration and system locality.

  acpi, numa: Use pr_fmt() instead of printk
  acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
  acpi, numa: remove duplicate NULL check
  acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
  arm64, acpi, numa: NUMA support based on SRAT and SLIT
  acpi, numa: Enable ACPI based NUMA on ARM64
  acpi, numa: move acpi_numa_slit_init() to common place
  arm64, numa: rework numa_add_memblk()
  x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
  acpi, numa: move bad_srat() and srat_disabled() to common place
  acpi, numa: remove unneeded acpi_numa=1
  acpi, numa: reuse acpi_numa_memory_affinity_init()

[1] http://lwn.net/Articles/672329/

http://vger.kernel.org/majordomo-info.html
http://wiki.xen.org/wiki/Xen_on_NUMA_Machines
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

DAQRI Smart Helmet powered by AMI firmware

Firmware vendor AMI announced that it is building the firmware for the DAQRI smart helmet.

Excerpt of AMI press release:

[…] DAQRI, a company known for its innovative work in augmented reality, recently announced the next generation of its flagship product, DAQRI SMART HELMET. Powered by a 6th generation Intel® CORE™ m7 processor and Intel® RealSense™ camera technology, DAQRI SMART HELMET is a wearable human-machine interface (HMI) giving workers in industrial sectors a whole new way of seeing data while on the job. The Smart Helmet is designed to work in enterprise settings and displays real-time information based on the user’s surroundings, increasing safety and worker productivity. It comes equipped with many features to enhance user awareness including: 4D/augmented reality, thermal vision, and industry leading Intellitrack™ computer vision technology. With increasing interest in augmented reality technology, AMI has collaborated with DAQRI in the development of the next generation DAQRI SMART HELMET. […]

http://ami.com/news/press-releases/?PressReleaseID=350&/American%20Megatrends%20Collaborates%20with%20DAQRI%20on%20the%20Next%20Generation%20of%20DAQRI%20SMART%20HELMET%E2%84%A2%20Augmented%20Reality%20HMI/

http://daqri.com/home/product/daqri-smart-helmet/

ARM-based AMD device launched

AMD has used to be x64-based company. But now they’ve also got ARM technology in some of their new products, so things are about to get interesting, how this will turn out.,. Joel Hruska reports in ExtremeTech on the Opteron-A1100:

http://www.extremetech.com/extreme/221282-amds-first-arm-based-processor-the-opteron-a1100-is-finally-here?sf19369490=1

AMD’s first ARM-based processor, the Opteron A1100, is finally here

Today AMD is formally launching its first ARM processor core, the Opteron A1100. AMD first announced its plans to enter the ARM market in 2013, with the chip expected to ship by mid-2014. The company apparently began early sampling around that time frame, but is only now launching the processor. The new Opteron A1100 is pretty much what AMD promised in its early previews of the device. It packs eight Cortex-A57 CPU cores, with each pair of cores sharing a 1MB L2 (512K effectively allocated to each chip). An 8MB L3 cache backs the entire CPU cluster, and the CPU supports both DDR3 and DDR4. ECC support is also provided.

Windows 10 health check features

https://twitter.com/dfullerto/status/690555872917987328

Microsoft has an article that describes the new health check security features of Windows 10, which include use of UEFI Secure Boot and TPM technology, among others:

This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows 10-based devices, including hardware requirements.

https://technet.microsoft.com/en-us/library/mt592023%28v=vs.85%29.aspx

Google Android Nexus debug cable is open source

Google has specs for the Nexus debug cable:

USB debug cable design documents:  Eagle schematics and PCB, gerber files, and BOM for a debug cable
for the headset serial port found on most Nexus devices.

https://android.googlesource.com/device/google/debugcable/+/master

Bill of Materials for Things

As Dyngnosis says:

“Bill of Materials for embedded devices could/should include a list of included 3rd party libraries. (Think heartbleed on an infusion pump)”

Consumers should know a lot more about the details of what is included in firmware. U-Boot has SPDX metadata.

 

Kali 2016.1 UEFI user experience notes

Debian Derivative-based Kali just released a new release, with UEFI support, based on upstream Debian. J.A. Watson wrote an article for ZDNet about trying to install the latest release, focusing on UEFI issues. I’ve included a few UEFI-centric excerpts below. Additionally it sounds like the Kali Mini version is based on Debian netinstall, “but it doesn’t boot on a UEFI system”.

[…]  To top it all off, the new distribution is UEFI compatible, and installed without any problem on the systems I have tried so far. This is really the best news of all for me, because I have spent huge amounts of time fighting to get the previous Kali distributions properly loaded and configured on UEFI systems (NOT in Legacy boot mode). […]  It looks to me like what they have finally done is what I thought they should have been doing all along – they simply use the Debian installer, which has been able to deal with UEFI for ages. […] The new ISO images can be obtained from the Kali Downloads page, and these are also a pretty impressive creation. They can be booted in (normal) Live mode, in (forensic) Live mode, or they can be directly installed. As far as I can tell there is no way to install from a Live boot, and I consider that to be a good thing because the previous Live installers didn’t work worth beans on UEFI firmware systems. […] The bottom line is, the new Kali release is here, it’s beautiful, it works, even on UEFI firmware. […]

Full article:
http://www.zdnet.com/article/hand-on-with-kali-linux-rolling/
https://www.kali.org/news/kali-linux-rolling-edition-2016-1/

Hackaday on Intel ME

Hackaday has a new blog on the Intel ME, covering recent news, as well as some background history I’d not seen.

[…] To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that’s used in the firmware remains an unsolved problem. But unsolved doesn’t mean that people aren’t working on it. There are efforts to break the ME’s Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now. […]

The Trouble With Intel’s Management Engine

FYI: This blog was Hackaday’s first UEFI-tagged post. A few others had BIOS tags.