The modding site Tweaktown.com has a forum on the Intel ME, which has a LOT of interesting links:
http://forums.tweaktown.com/gigabyte/54860-about-intel-management-engine-firmware.html#post469078
The modding site Tweaktown.com has a forum on the Intel ME, which has a LOT of interesting links:
http://forums.tweaktown.com/gigabyte/54860-about-intel-management-engine-firmware.html#post469078
Enno Ray points out that The Krypt has a new article focusing on FreBSD security features:
Even if you are a Linux-only person, who doesn’t care about FreeBSD, you still may want to read this to get an understand of Matthew Garret’s BSD-based sedurelevel patch that improves Linux Secure Boot security. 🙂
This from September, I only just noticed it. 😦
Matthew Garrett has updated GRUB bootloader with support for Trusted Boot, on TPM v1 or v2 systems!
In a follow-up to the above tweet, Matthew also states:
“I need to add equivalent code to Shim now lucky me”
So I need to check if that happened, and if Debian and other distros are using this version of GRUB and Shim…
I wish somebody — Wikipedia, the Linux Foundation, the Linux kernel security wiki, the UEFI Forum, etc. — were tracking the various hardware/firmware security features of various vendors, and what system components (grub and shim in this case) had support for the various technologies, with a table of red/green boxes. Then we could more easily see things like tboot only supporting BIOS and not UEFI, etc..
Naked Security has a story about the FCC and BadBIOS-like warnings about TVs:
BadBIOS is back
One of the most intriguing – and perhaps the most outlandish – technique for cross-device tracking is mentioned in the public comment submitted to the FTC’s workshop by the DC-based Center for Democracy and Technology (CDT). The CDT makes reference to an Indian company that claims to offer a TV-to-smartphone tracking system that works, if you can believe it, using ultrasound. Just like the BadBIOS controversy from late 2013, which was supposed to be hardware-level malware that could steal data even across a so-called network “air gap,” such as the one that exists between the average TV and smartphone. The idea is that you can use regular audio waves to transmit data between two computers that have no other sort of network connection.
Full article:
There’s a new Kickstarter project for an “open source hardened computer”, called ORWL by Design SHIFT:
I am unclear on their additional security features… Read the ‘thread’ on the above Twitter thread, eg:
https://twitter.com/rootkovska/status/666219351553495040
https://twitter.com/Orwlr/with_replies
WordPress renders Kickstarter URLs by only showing the video, hiding the rest of the page, remove the linefeed below:
https://www.kickstarter.com
/projects/designshift/orwl-the-first-open-source-hardened-computer
Black Hat EU 2015 presentations online
https://www.blackhat.com/eu-15/briefings.html
There is a presentation for AndroBugs Framework:
There is a presentation on bypassing SEDs (Self-Encrypting Disks):
Yu-Cheng Lin’s AndroBugs 1.0.0 has been released:
AndroBugs Framework is an Android vulnerability analysis system that helps developers or hackers find potential security vulnerabilities in Android applications. No splendid GUI interface, but the most efficient (less than 2 minutes per scan in average) and more accurate. Features:
* Find security vulnerabilities in an Android app
* Check if the code is missing best practices
* Check dangerous shell commands (e.g. “su”)
* Collect Information from millions of apps
* Check the app’s security protection (marked as <Hacker>, designed for app repackaging hacking)
There’s a review of a new MSI system on Gamers Nexus by Steve Brooke. I enjoyed his comments on the usability issues with UEFI diagnostics the OEM/IBV provided, including last comment from gamer perspective on lack of need of TPM. 😦 I have yet to find a hardware reviewer that includes information from CHIPSEC, showing if the machine is shipped with known firmware vulnerabilities. 😦
“The UEFI board explorer is probably one of MSI’s best features. It’s nothing particularly exciting to experienced builders, but makes for excellent usability and education for newcomers to PC building. Board explorer detects mice, some keyboards, video cards, and other devices, and accurately reports which port they’re plugged into on the board. This makes it easy to see which slots are utilized and what devices are using them.
The Hardware Monitor is probably where we spend most of our time in testing. Hardware Monitor offers basic reporting on the PC’s status and specs, with fan speed, boot, and low-level configuration and controls. The graphical display of fan curves in MSI’s B150A UEFI provides a click-and-drag interface for adjusting fan speed vs. temperatures with smooth input. This somewhat resembles host-level software curve creation, but at a lower-level. We’d really like to see this functionality expand to liquid cooler pump motors so that we can read-out RPMs of CLCs. We’d also like to see breadcrumbs added to UEFI to offer a path->to->current navigation. Regarding temperature accuracy, using our thermal measurement equipment, all thermals appear accurately represented within BIOS.
One thing that’s a little useless: The voltage level graph, which reports vCore and other voltages, has no scale – so it’s just sort of randomly illustrated bars representing an ambiguous, undefined voltage level. Might as well get rid of the graph and just read-out numbers, in that case.
Overclocking profiles are pretty straight-forward for what you’d get on a B-series motherboard. Users can save and load via ROM and USB, which is great for backups and testing, but that doesn’t make it any more in-depth – OCing is still locked. It’s not a Z-series board, so the best we can get is forcing Turbo. Overclocking profiles are “normal” and “expert,” and can perform some modest RAM timing and overclocking control alongside the forced Turbo. Voltage adjustment is present in the event that the forced Turbo needs more power to stabilize, though that’s unlikely.
We saw that Thunderbolt is in the UEFI menu, but without any Thunderbolt ports on the motherboard. Asking MSI about this, we learned that the menu support exists for Thunderbolt add-in cards.
TPM and basic security features exist for business users, though why they’d buy a “gaming” board is questionable.”
http://www.gamersnexus.net/hwreviews/2186-msi-b150a-gaming-pro-motherboard-review#!/ccomment
The US Government policy towards permitting it’s citizens to create/modify firmware on some forms of devices has been clarified:
More info:
http://www.extremetech.com/internet/218017-fcc-removes-reference-to-dd-wrt-from-guidelines-swears-it-will-not-ban-third-party-router-firmware
http://arstechnica.com/information-technology/2015/11/fcc-we-arent-banning-dd-wrt-on-wi-fi-routers/
http://www.theregister.co.uk/2015/11/12/fcc_revises_router_update_rules/
http://hightechforum.org/fcc-clarifies-the-ask-for-wi-fi-routers/
Alex Hung of Canonlical has announced the release of FWTS (FirmWare Test Suite) version 15.11.00, the November 2015 quarterly release, with multiple changes to the UEFI and ACPI tools.
= Significant Updates =
* Update ACPICA to version 20150930
= New Features =
* Add in the notion of ACPI compliance tests.
* MADT subtables: Local SAPIC structure has 3 reserved bytes, not 1
* ACPI: MADT: update GICC flag checks for ACPI 6.0
* ACPI: MADT: further update to GICC flag checks for 6.0
* acpi: method: skip scope names in method_evaluate_method
* acpi: method: add _GPE test
* acpi: method: add _TSN test
* acpi: method: add _TFP test
* acpi: method: add _EC test
* acpi: method: add _CWS test
* acpi: method: add _BTH test
* auto-packager: mkpackage.sh: add xenial
* acpi: tpm2: add check for zero control area address (LP: #1506442)
* securebootcert: change fail to warning when MS UEFI CA not found in DB
* lib: fwts_uefi: add BMC device path define
* uefidump: add dumping the BMC device path
* uefibootpath: add test for the BMC device path
* lib: fwts_uefi: add the URI device path define
* uefibootpath: add test for the URI device path
* uefidump: add dumping for the URI device path
* lib: fwts_uefi: add the UFS device path define
* uefidump: add dumping for the UFS device path
* uefibootpath: add test for the UFS device path
= Fixed Bugs =
* dmi: dmicheck: fix SMBIOS issues on aarch64 systems
* acpidump: add missing reserved fields to MADT structures
* cpufreq: the calibration is taking a long time, make it faster
* acpi: tcpa: replace tab with spaces to fix formatting alignment
More Information:
http://fwts.ubuntu.com/release/fwts-V15.11.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.11.00
https://launchpad.net/ubuntu/+source/fwts
Aurelien Jacquiot of TI recently submitted a patch to U-Boot, adding support for RapidIO, initially designed to support the TI KeyStone architecture. Comments from initial patch message:
“RapidIO is a high-performance packet-switched interconnect technology that can be used for messaging or memory transfers like Ethernet or PCIe. This feature adds the RapidIO boot functionality for slave mode (i.e. U-Boot does not fetch the images, images are pushed by a peer device/board). A new ‘rio’ command group allows to initialize and perform basic RapidIO operations. In addition the ‘mem’ group command has been enhanced in order to wait a given value in memory (to be notified that images have been pushed by peer). This feature has been firstly designed for TI KeyStone architecture and patches includes the RapidIO controller device driver for KeyStone architecture but it can used by any device/architecture that has hardware RapidIO support with DirectI/O. There just to add the corresponding RapidIO controller device driver. For more information, read the doc/README.rapidio documentation.”
More Information:
http://www.rapidio.org/
http://lists.denx.de/mailman/listinfo/u-boot
http://www.ti.com/sitesearch/docs/universalsearch.tsp?searchTerm=RapidIO#
Firmware.RE is getting some more publicity today, from this post from Travis Goodspeed:
Firmware.RE is a web service where you can upload a ROM to have it analyzed. A bit more information here:
I’m unclear if the source to the site is open source or not.
Check out the thesis paper behind the site:
Besides UEFI Spyder’s scripts, and Apple-centric Firmware Vault, does anyone know of any public repositories of ROMs, for security researchers? If so, please leave a Comment (see left).
Earlier I was starting to create a list of Twitter feeds of firmware-related security researchers, since many use Twitter exclusively these days. But I have been hesitant to continue this, in case I don’t know about some researchers and not list them, etc. I’d rather let others manage the list, and luckily Jacob Torrey created a Twitter ‘firmware-security’ list so you can join yourself and I don’t have to create/maintain a list!
https://twitter.com/JacobTorrey/lists/firmware-security
In addition to Twitter, there still are a few people who use blogs. Vincent Zimmer has been blogging on firmware for a long time, and he’s got the definitive post on firmware blogs:
http://vzimmer.blogspot.com/2015/06/firmware-related-blogs.html
I don’t know anything about Usenet, IRC/XMPP/IM, Reddit, Facebook, LinkedIn, Google+, or other social network communities which cover firmware security issues. If you know of one, please leave a comment on this blog (see left), or email me (see upper right).
For a future blog post, I’ll create a list of firmware-related mailing lists.
I noticed a somewhat recent blog post from Giacomo aka “Jacksoft”, an Italian firmware modder, called “VIAOgeddon”, covering his latest BIOS modding adventure on the firmware of his Sony VIAO. A very thorough post, with dozens of posted images and links. I’ll just excerpt the last paragraph and his list of tags:
“WARNING, I’LL NOT ASSUME ANY RESPONSIBILITY ABOUT THIS ARTICLE AND FILES/SOFTWARE LINKED, PUBLICIZED AND MENTIONED HERE! BIOS MODDING IS REALLY DANGEROUS AND COULD BRICK OR DAMAGE YOUR MACHINE! BE SURE TO KNOW WHAT ARE YOU DOING AND POSSIBLY HAVE AN SPI DUMP OF YOUR FULL BIOS!!!”
“Tags: afuwin, amibcp, ati, bios, dual bios, hack, intel, intel bmp, intel fit, mmtool, mod, o-rom, R0300Y8, R1170Y8, sony, vaio, vbios, vpceb4c5e.”
http://blog.jacksoftlabs.com/vaiogeddon/
I try to follow the embedded/firmware development as well as firmware security communities. I really don’t know much about the firmware modding communities. Besides a few English-based forums, I hear there are some Russian and Chinese ones, but the Mandarain CAPTCHAS would keep me out of the latter, probably both, as I can barely make it through some English CAPTCHAS. 🙂
Kees Cook has a blog on seccomp, including a discussion of the new OpenBSD pledge technology, a bit of BSD -vs- Linux kernel security comparisons:
http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.html
Alex Ionescu has a paper discussing Windows 10’s use of Intel SGX:
Jethro Beekman, author of UEFIreverse, has an excellent blog post on UEFI reversing, showing how he uses these tools!
https://jbeekman.nl/blog/2015/03/reverse-engineering-uefi-firmware/
US-CERT reports that Google has Released Security Updates for Chrome and Chrome OS
“Google has released security updates to address vulnerabilities in Chrome and Chrome OS. Exploitation of one of these vulnerabilities may allow a remote attacker to take control of an affected system. Updates available include:
* Chrome 46.0.2490.86 for Windows, Mac and Linux
* Chrome 46.0.2490.82 for all OS devices
Users and administrators are encouraged to review the Chrome page and Chrome OS page and apply the necessary updates.”
More Info:
http://googlechromereleases.blogspot.com/2015/11/stable-channel-update-for-chrome-os.html
http://googlechromereleases.blogspot.com/2015/11/stable-channel-update.html
https://www.us-cert.gov/ncas/current-activity/2015/11/11/Google-Releases-Security-Updates-Chrome-and-Chrome-OS
Al Stone of Red Hat announced on the Linaro Firmware Summit mailing list that the list would transition over to the new UEFI Forum’s FW/OS list. Excerpt of announcement:
Since the fw-summit mailing list was only meant as a holding place until we could set up a forum like this, we will soon be disabling the mailing list. Any and all of the discussions we would have had on fw-summit should now be held on the FW/OS Forum mailing list instead. […] I would like to thank Dong Wei of UEFI especially, but also Michael Krau and the rest of the board of the UEFI Forum for all of their hard work and effort to make this public forum possible. It was a bit of a stretch for everyone, but it got done. Thanks!
Full announcement:
https://lists.linaro.org/pipermail/fw-summit/2015-November/000184.html
http://www.uefi.org/FWOSForum
https://lists.linaro.org/pipermail/fw-summit/
https://lists.linaro.org/mailman/listinfo/fw-summit
Drew Fustini points out a Linux security project I’ve never heard of:
This project starts with the premise that kernel bugs have a very long lifetime, and that the kernel must be designed in ways to protect against these flaws. We must think of security beyond fixing bugs. As a community, we already find and fix individual bugs via static checkers (compiler flags, smatch, coccinelle, coverity) and dynamic checkers (kernel configs, trinity, KASan). Those efforts are important and on-going, but if we want to protect our billion Android phones, our cars, the International Space Station, and everything else running Linux, we must get proactive defensive technologies built into the upstream Linux kernel. We need the kernel to fail safely, instead of just running safely. These kinds of protections have existed for years in PaX, grsecurity, and piles of academic papers. For various social, cultural, and technical reasons, they have not made their way into the upstream kernel, and this project seeks to change that. Our focus is on kernel self-protection, rather than kernel-supported userspace protections. The goal is to eliminate classes of bugs and eliminate methods of exploitation.
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Discover the Desktop
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
News from coreboot world
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Just another WordPress.com site
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
You must be logged in to post a comment.