Author: hucktech

coreboot 4.8 released

~ hucktech ~ Leave a comment

https://www.phoronix.com/scan.php?page=news_item&px=Coreboot-4.8-Released

https://coreboot.org/releases/coreboot-4.8-relnotes.txt

https://mail.coreboot.org/pipermail/coreboot/2018-May/086729.html

https://mail.coreboot.org/pipermail/coreboot/2018-May/086757.html

https://mail.coreboot.org/pipermail/coreboot/2018-May/086700.html

Unnamed Reverse Engineering Podcast: Debug Interfaces

~ hucktech ~ Leave a comment

010 – T0015! Part 0x3 – Debug Interfaces

This week we talk about the nebulous world of debugging interfaces, some of their history, and how they can be used in reverse engineering. We cover the basics of what are JTAG and SWD ( both ARM Debug Access Port (DAP) and ARM® Debug Interface Architecture Specification) and can they both be used to debug a MIPS processor (the answer is NO!). We list a few other standards but also some key vendors and projects to get you debugging and controlling your next system: Segger J-Link/J-Trace (generally the most flexible), BlackMagicProbe, ST-Link, BusBlaster, JTAGulator, Cypress Miniprog3,Microchips supports both AVR and Microchip parts for debug.[…]

http://reverseengineering.libsyn.com/

 

Shattered Trust: When Replacement Smartphone Components Attack

~ hucktech ~ Leave a comment

Shattered Trust: When Replacement Smartphone Components Attack
(Submitted on 13 May 2018)

Phone touchscreens, and other similar hardware components such as orientation sensors, wireless charging controllers, and NFC readers, are often produced by third-party manufacturers and not by the phone vendors themselves. Third-party driver source code to support these components is integrated into the vendor’s source code. In contrast to ‘pluggable’ drivers, such as USB or network drivers, the component driver’s source code implicitly assumes that the component hardware is authentic and trustworthy. As a result of this trust, very few integrity checks are performed on the communications between the component and the device’s main processor. In this paper, we call this trust into question, considering the fact that touchscreens are often shattered and then replaced with aftermarket components of questionable origin. We analyze the operation of a commonly used touchscreen controller. We construct two standalone attacks, based on malicious touchscreen hardware, that function as building blocks toward a full attack: a series of touch injection attacks that allow the touchscreen to impersonate the user and exfiltrate data, and a buffer overflow attack that lets the attacker execute privileged operations. Combining the two building blocks, we present and evaluate a series of end-to-end attacks that can severely compromise a stock Android phone with standard firmware. Our results make the case for a hardware-based physical countermeasure.

https://arxiv.org/abs/1805.04850

NetHammer

~ hucktech ~ Leave a comment

https://twitter.com/campuscodi/status/996358282049736704

Nethammer: Inducing Rowhammer Faults through Network Requests

(Submitted on 13 May 2018)

A fundamental assumption in software security is that memory contents do not change unless there is a legitimate deliberate modification. Classical fault attacks show that this assumption does not hold if the attacker has physical access. Rowhammer attacks showed that local code execution is already sufficient to break this assumption. Rowhammer exploits parasitic effects in DRAM to modify the content of a memory cell without accessing it. Instead, other memory locations are accessed at a high frequency. All Rowhammer attacks so far were local attacks, running either in a scripted language or native code. In this paper, we present Nethammer. Nethammer is the first truly remote Rowhammer attack, without a single attacker-controlled line of code on the targeted system. Systems that use uncached memory or flush instructions while handling network requests, e.g., for interaction with the network device, can be attacked using Nethammer. Other systems can still be attacked if they are protected with quality-of-service techniques like Intel CAT. We demonstrate that the frequency of the cache misses is in all three cases high enough to induce bit flips. We evaluated different bit flip scenarios. Depending on the location, the bit flip compromises either the security and integrity of the system and the data of its users, or it can leave persistent damage on the system, i.e., persistent denial of service. We investigated Nethammer on personal computers, servers, and mobile phones. Nethammer is a security landslide, making the formerly local attack a remote attack.

https://arxiv.org/abs/1805.04956

 

uefi-tool-debug: freeware (no source): a little tool used to check your uefi system

~ hucktech ~ Leave a comment

NOTE: this is a binary-only project, no source code. As always, be very careful running 3rd party ISV freeware. This binary may include malware. 🙂

https://github.com/qyqgit/uefi-tool-debug

a little tool used to check your uefi system. 一个简单的小工具用来访问uefi系统的各种资源。刚接触这方面的东西，希望有疏漏错误的地方多多交流指正，谢谢。

 

 

EPA-RIMM: A Framework for Dynamic SMM-based Runtime Integrity Measurement

~ hucktech ~ Leave a comment

EPA-RIMM: A Framework for Dynamic SMM-based Runtime Integrity Measurement
Brian Delgado, Karen L. Karavanic
(Submitted on 9 May 2018)

Runtime integrity measurements identify unexpected changes in operating systems and hypervisors during operation, enabling early detection of persistent threats. System Management Mode, a privileged x86 CPU mode, has the potential to effectively perform such rootkit detection. Previously proposed SMM-based approaches demonstrated effective detection capabilities, but at a cost of performance degradation and software side effects. In this paper we introduce our solution to these problems, an SMM-based Extensible, Performance Aware Runtime Integrity Measurement Mechanism called EPA-RIMM. The EPA-RIMM architecture features a performance-sensitive design that decomposes large integrity measurements and schedules them to control perturbation and side effects. EPA-RIMM’s decomposition of long-running measurements into shorter tasks, extensibility, and use of SMM complicates the efforts of malicious code to detect or avoid the integrity measurements. Using a Minnowboard-based prototype, we demonstrate its detection capabilities and performance impacts. Early results are promising, and suggest that EPA-RIMM will meet production-level performance constraints while continuously monitoring key OS and hypervisor data structures for signs of attack.

https://arxiv.org/abs/1805.03755

http://web.cecs.pdx.edu/~karavan/research/SMM.html

FirmWare Test Suite 18.05.00 released

~ hucktech ~ Leave a comment

New Features:
* fan: add cooling_device# to error messages
* doc: adding acpitests, uefitests and sbbr options to man page
* acpi: syntaxcheck: change it from batch to batch-experimental
* fwts_framework: add an “ifv” option for Independent Firmware Vendor
* dmicheck: skip checks of DMI default values for IFV
* acpi: method: add test for _CLS control method
* lib: create helper functions for device identification objects
* acpi: devices: add common objects
* fwts-frontend-text: add a recommended option for IFV (IBV)
* fwts-frontend-text: add an option for ARM SBBR
* auto-packager: mkpackage.sh: add cosmic
* ACPICA: Update to version 20180427
* ACPICA: Update to version 20180508
* README: Add libpci-dev dependency ppc64el
* cpufreq: Add support to read boost frequencies

See announcement for list of bugfixes.

https://lists.01.org/pipermail/luv/2018-May/002735.html
http://fwts.ubuntu.com/release/fwts-V18.05.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/18.05.00
https://launchpad.net/ubuntu/+source/fwts

New Hacking Tool Lets Users Access a Bunch of DVRs and Their Video Feeds

~ hucktech ~ Leave a comment

TBK DVR4104 and DVR4216 devices, as well as Novo, CeNova, QSee, Pulnix, XVR 5 in 1, Securus, Night OWL, DVR Login, HVR Login, and MDVR Login, which run re-branded versions of the original TBK DVR4104 and DVR4216 series, allow remote attackers to bypass authentication via a “Cookie: uid=admin” header, as demonstrated by a device.rsp?opt=user&cmd=list request that provides credentials within JSON data in a response.

[*] Exploit Title: “Gets DVR Credentials”
[*] CVE: CVE-2018-9995
[*] CVSS Base Score v3: 7.3 / 10
[*] CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
[*] Date: 09/04/2018
[*] Exploit Author: Fernandez Ezequiel ( twitter:@capitan_alfa )

http://misteralfa-hack.blogspot.com/2018/04/tbk-vision-dvr-login-bypass.html

https://github.com/ezelf/CVE-2018-9995_dvr_credentials

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9995

https://nvd.nist.gov/vuln/detail/CVE-2018-9995

https://gizmodo.com/a-creepy-website-is-streaming-from-73-000-private-secur-1655653510

https://www.bleepingcomputer.com/news/security/new-hacking-tool-lets-users-access-a-bunch-of-dvrs-and-their-video-feeds/

A guide to better embedded C++

~ hucktech ~ Leave a comment

A guide to better embedded C++

[…]The motivation behind this post is pretty simple: there is a lot (A LOT) of bad embedded code. There are several reasons for that:

* No background programming experience or education. Very often electronics students are taught plain C or C with classes (watch Kate talk about that).

* Difficult debugging. Most embedded systems are slow and have very limited debug abilities (sometimes even none of them at all). This is not a problem per se but may lead to numerous hotfixes and spaghetti code.

* Exotic architectures (where the byte is 24 and 32 bit long) with various compilers. Previously it used to be mostly custom stuff, but now processor manufacturers tend to fork some GCC or LLVM version and build a custom toolchain. This leads to problems with code reuse and significantly slows down the new standards adoption.

[…]

https://mklimenko.github.io/english/2018/05/13/a-guide-to-better-embedded/

Device Programming wiki: documents devices and protocols to read/write EPROMS, PALs, and other chips

~ hucktech ~ Leave a comment

The device programming wiki is a community resource for protocols and devices that read or write commercially available ICs. We are focusing on older devices (ex: EPROMs) that require more exotic voltages and/or connections than modern devices using protocols like JTAG.

http://proghq.org/wiki/Main_Page

 

bunnie launches NeTV2, open source video dev board, on CrowdSupply

~ hucktech ~ 1 Comment

https://www.crowdsupply.com/alphamax/netv2

https://www.bunniestudios.com/blog/?p=5308

ARM64JSON: AArch64 instructions encoded in JSON

~ hucktech ~ Leave a comment

https://twitter.com/kov4l3nko/status/995433621925384192

 

The repository contains ARM64 (AArch64) instruction encoding in a machine-readable JSON:

* ISA_v83A_A64_xml_00bet6_instructions.json contains encoding of every instruction, including ARM64v2/v3 extensions.

* ISA_v83A_A64_xml_00bet6_group_class.json contains hierarchical encoding ARM64 top level -> Instruction group (e.g. “Data Processing — Immediate”) -> Instruction class (e.g. “Add/subtract (immediate)”). No instruction encodings in this file.

The simple and easyly-organised JSON data was extracted from a machine-readable ARM64 specs. A64 ISA XML for Armv8.3 ver. 00bet6.1 released by ARM.

https://github.com/kov4l3nko/ARM64JSON

See-also:

ARM: documents CSDB (Consumption of Speculative Data Barrier) instruction

ARM Releases Machine Readable Architecture Specification

 

fwupd / LVFS and user privacy

~ hucktech ~ Leave a comment

There’s been a few blog posts from the LVFS project and the System76 team regarding firmware updates.

Don’t buy System76 hardware and expect to get firmware updates from the LVFS

System76: System76 and LVFS – what really happened

The latest article is from FOSSpost.org by M.Hanny Sabbagh, which focuses on privacy issues of LVFS, from the last System76 article. While privacy issues are important, don’t forget that firmware update privacy issues exist with ALL other OSes, and LVFS team mentions transition to Linux Foundation for hosting. Most firmware updates come from OEM, so each will have their own CDN/privacy/security issues. I’m hoping the LVFS project gets picked up by the Qubes/TAILS/Subgraph/GNUHardenedLinux or some other privacy/security-centric distro, and can integrate with latest security and privacy techniques, making it Tor-friendly, etc.

See threads here and comments in fosspost.org blog post, and in Twitter feed:

https://lists.debian.org/debian-efi/2018/05/threads.html

https://fosspost.org/analytics/privacy-security-concern-regarding-gnome-software

Diverse Lynx: seeks PenTester to use CHIPSEC [against Lenovo?]

~ hucktech ~ Leave a comment

Lenovo working throug an external pentest firm? Wish I saw more OEMs asking for appropriate job skills.

If you’re thinking about applying, look at some of the reviews for this consulting firm before doing so. Maybe look if Lenovo has a direct position open as well.

Diverse Lynx: Penetration tester
[…]It is also firmware analysis which according to Lenovo is analyzing anything that may be on disk. […] Chipsec needs to be used for this assessment. It’s for UEFI attacks, but it’s fairly automated.[…]

https://www2.jobdiva.com/candidates/myjobs/openjob_outside.jsp?id=10760288

https://www.diverselynx.com/

 

CVE-2018-8897: Debug Exception May Cause Unexpected Behavior

~ hucktech ~ Leave a comment

A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer’s Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS, as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. The MOV to SS and POP SS instructions inhibit interrupts (including NMIs), data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction (SDM Vol. 3A; section 6.8.3). (The inhibited data breakpoints are those on memory accessed by the MOV to SS or POP to SS instruction itself.) Note that debug exceptions are not inhibited by the interrupt enable (EFLAGS.IF) system flag (SDM Vol. 3A; section 2.3). If the instruction following the MOV to SS or POP to SS instruction is an instruction like SYSCALL, SYSENTER, INT 3, etc. that transfers control to the operating system at CPL < 3, the debug exception is delivered after the transfer to CPL < 3 is complete. OS kernels may not expect this order of events and may therefore experience unexpected behavior when it occurs.

https://www.triplefault.io/2018/05/spurious-db-exceptions-with-pop-ss.html

Click to access popss.pdf

https://software.intel.com/en-us/articles/intel-sdm

https://www.kb.cert.org/vuls/id/631579
https://nvd.nist.gov/vuln/detail/CVE-2018-8897
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8897
http://openwall.com/lists/oss-security/2018/05/08/1
http://openwall.com/lists/oss-security/2018/05/08/4

https://github.com/torvalds/linux/commit/d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9
https://patchwork.kernel.org/patch/10386677/
https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-8897.html
https://security-tracker.debian.org/tracker/CVE-2018-8897
https://kb.vmware.com/s/article/54988
https://bugzilla.redhat.com/show_bug.cgi?id=1567074
https://support.apple.com/HT208742
https://svnweb.freebsd.org/base?view=revision&revision=333368
https://www.freebsd.org/security/advisories/FreeBSD-SA-18:06.debugreg.asc
https://xenbits.xen.org/xsa/advisory-260.html
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8897

System76: System76 and LVFS – what really happened

~ hucktech ~ 1 Comment

Re: https://firmwaresecurity.com/2018/05/10/dont-buy-system76-hardware-and-expect-to-get-firmware-updates-from-the-lvfs/ this is the Sytem76 side of the story:

The Future of Firmware

LVFS and UpdateCapsule might be okay for companies mostly focused on a proprietary future (Logitech, Dell, etc.). UpdateCapsule is not the technique companies will use in a future of open source firmware—the future we’re working toward. Liberating firmware is going to be a long and challenging process. Much like Free Software has replaced proprietary software over time, we must chip away at the proprietary firmware pieces within the hardware supply chain. Manufacturing is the first step. This year we’ll manufacture open source desktop designs in our Denver plant. The CAD will be free to download, change, and produce. There will be a separate, open source electrical design and open source firmware daughter board to control functions within the desktop. On a mainboard there is the BIOS chip and one or more embedded controllers that manage fans, keyboard, LEDs, hotkeys and other critical functions. It’s all proprietary. Our strategy is to move this functionality from the proprietary mainboard to the open source daughter board. Then anyone can create a PCB with basic computer functionality, understand how it works, and improve upon the work. One could have this PCB made at Osh Park, install it in their desktop, tune it, and replace a bunch of proprietary firmware instantly. We’ll grow from there. Slowly we’ll chip away at more and more of the mainboard functions until what’s left is Intel and AMD bits. Then there’s the challenge of convincing them to go open. There’s room for cautious optimism.[…]

http://blog.system76.com/post/173801677358/system76-and-lvfs-what-really-happened

Who is working to fix (unify) Linux firmware solutions? UEFI Forum? Linux Foundation? I don’t see a single OEM (eg, System76) driving any such standardization. … 😦

Throwhammer

~ hucktech ~ Leave a comment

https://arstechnica.com/information-technology/2018/05/attackers-trigger-rowhammer-bit-flips-by-sending-network-packets-over-a-lan/

https://securityaffairs.co/wordpress/72377/hacking/throwhammer-rowhammer-attack.html

INTEL-SA-00106: Intel Integrated Performance Primitives Cryptography Library Update

~ hucktech ~ Leave a comment

Intel ID: INTEL-SA-00106
Product family: Intel® Integrated Performance Primitives
Impact of vulnerability: Information Disclosure
Last revised: 05/10/2018

Some implementations in Intel® Integrated Performance Primitives Cryptography Library before version 2018 U2.1 do not properly ensure constant execution time. Intel recommends that users of Intel® Integrated Performance Primitives Cryptography Library evaluate their implementations and update to IPP 2018 U2.1 as appropriate. Intel thanks Ahmad Moghimi, Thomas Eisenbarth, and Berk Sunar from Worcester Polytechnic Institute for reporting this issue.[…]

https://registrationcenter.intel.com/en/forms/?productid=2717

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00106.html

INTEL-SA-00135: Intel SGX Platform Software

~ hucktech ~ Leave a comment

Intel ID: INTEL-SA-00135
Product family: Intel® SGX SDK and Intel® SGX Platform Software
Impact of vulnerability: Information Disclosure
Last revised: 05/10/2018

Intel® Software Guard Extensions Software Development Kit (SDK) and Platform Software (PSW) utilize the Intel® Integrated Performance Primitives Cryptography Library. Vulnerabilities in this cryptography library have been reported that may enable a local attacker running malware utilizing software based side channel methods to gather data concerning certain cryptographic keys. In accordance with the recent public security advisory INTEL-SA-00106 published for the Intel® Integrated Performance Primitives Cryptography Library, new versions of the Intel® SGX SDK and Intel® SGX PSW have been released.[…]

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00135.html