Uncategorized

Senrio+Xipiter 0day for MANY D-Link devices

[…] In our last post we talked about a vulnerability discovered in the D-Link DCS-930L Cloud Camera. Since then the Senrio Research Team has been working closely with the D-Link Security Incident Report Team. Below we disclose technical details of our efforts.  […] What does that mean in terms of exposure to consumers? In a collaboration with Shodan we discovered 400,000 devices publicly accessible that could be affected by this 0day.  […]

http://blog.senr.io/blog/400000-publicly-available-iot-devices-vulnerable-to-single-flaw

Standard
Uncategorized

Intrinsic-ID increase MIPS security

Steve Bush has an article in Eletronics Weekly about Imagination Technology — the company that owns MIPS chips — teaming with “Eindhoven chip security firm Intrinsic-ID to add a ‘physically un-cloneable function’ (PUF) to MIPS cores – initially the M5150 CPU – for authentication and anti-cloning.”

Imagination increases security on MIPS processors

Standard
Uncategorized

Imagination donates MIPS hardware to Debian

It looks like a few companies, including Imagination Technologies, the current company behind MIPS processors, has donated some hardware to the Debian project!

 […] Imagination Technologies recently donated several high-performance SDNA-7130 appliances to the Debian Project for the development and maintenance of the MIPS ports. The SDNA-7130 (Software Defined Network Appliance) platforms are developed by Rhino Labs, a leading provider of high-performance data security, networking, and data infrastructure solutions. With these new devices, the Debian project will have access to a wide range of 32- and 64-bit MIPS-based platforms. […] The Debian project would like to thank Imagination, Rhino Labs and aql for this coordinated donation. […]

https://bits.debian.org/2016/05/imagination-64-bit-mips-cpus.html

PS: I mostly pay attention to Intel and ARM hardware, it’s been a while since I’ve worked on a MIPS box. Just catching up to MIPS after years, there’s a lot of firmware exploit research out there:
https://www.google.com/?gws_rd=ssl#q=MIPS+firmware+reverse+engineering
https://www.linux-mips.org/wiki/Firmware

Standard
Uncategorized

Bowcaster Exploit Development Framework, for MIPS

Zachary Cutlip has written an exploit framework for MIPS:

The Bowcaster Exploit Development Framework, implemented in Python, is intended to aid those developing exploits by providing useful set of tools and modules, such as payloads, encoders, connect-back servers, etc.  Currently the framework is focused on the MIPS CPU architecture, but the design is intended to be modular enough to support arbitrary architectures.

https://github.com/zcutlip/bowcaster
https://github.com/zcutlip/exploit-poc/tree/master/dlink/dir-815-a1/hedwig_cgi_httpcookie

Standard
Uncategorized

New Loongson MIPS chip runs ARM and x86 code

Loongson Technology has created the Loongson-3A2000 and Loongson-3B2000 chips, 64-bit quad-core MIPS64-based CPUs.

In addition to MIPS, these CPUs also run Intel x86 and ARM code, using LoongBT, a binary translation technology for Linux. The mind boggles with legal/IP complications…

I don’t know what firmware these new CPUs will use. There is an unofficial MIPS port of UEFI, but AFAIK but nothing official going on, so I presume the CPUs will use U-Boot or coreboot, but no details available AFAICT. I can’t find any details on LoongBT technology, either…

http://www.electronics-eetimes.com/en/chinese-processor-builder-discloses-mips64-ip-based-4-core-designs.html?cmp_id=7&news_id=222925960&vID=8
https://www.reddit.com/r/technology/comments/3jqg5o/chinas_loongson_makes_a_64bit_mips_processor_that/
http://blog.imgtec.com/mips-processors/loongson-mips64-processors-performance-barrier

Standard
Uncategorized

coreboot and Chrome OS upstreaming

I mainly work with UEFI technology, and don’t know much about coreboot, nor Chrome OS. I’m new to these tech, and learning them… 🙂

For a while, I thought coreboot was pretty inactive, but I now realize much of the coreboot activity has been taking place in Chrome OS. It appears that some of this work is now being upstreamed to the main coreboot.

From the coreboot blog:

“In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other. In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers. Significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip.”

“In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented.”

Some features that’ve been recently added include:
* new MIPS support
* improved ARM support, for SoCs by Broadcom, Marvell, Qualcomm, and RockChip
* an improved, safer method to declare the memory map on devices
* effort to get Chrome OS’ verified boot support
* update the flash image format to allow for safer incremental updates

This looks like great news for coreboot! I’ll have more blog entries about coreboot and Chrome OS in the near future.

More Information:
http://blogs.coreboot.org/blog/2015/05/26/report-on-chrome-os-upstreaming/
http://coreboot.org/
http://www.chromium.org/chromium-os/2014-firmware-summit
https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot

Standard