#aslr

Read the full report on -

Apple adds ‘BlastDoor’ to secure iPhones and iPads from zero-click attacks

Apple has added several anti-exploit mitigations, including a sandboxed “BlastDoor” service, into its flagship mobile operating systems, iOS 14 and iPadOS 14, in what appears to be a specific response to zero-click iMessage attacks observed in the wild. Ryan Naraine for SecurityWeek: The new mitigations were discovered by Samuel Groß, a Google Project Zero security researcher who specializes in…

VirtualProtectEx to bypass ASLR : A specific case study

Original text by Souhail Hammou 

VirtualProtectEx to bypass ASLR : A specific case study

More than a year ago, I developed a local privilege escalation exploit for a product (that I cannot disclose unfortunately) in which I had to bypass ASLR.

For the record, these are the protections enabled in the targeted service’s binary, it is a 32-bit executable running under Wow64 on 64-bit…

Today, I´d like to talk about some security features that either come standard with the Linux kernel, or can be compiled in as desired.

First on the list is the use of discretionary access controls. In Linux, this is handled through the use of users, groups, and permission bits. With some exceptions (notably NTFS and FAT), Linux-supported filesystems allow meta-information to be prepended to file entries that denote who can do what with a given file or directory, and this is represented by the aforementioned permission bits; any file can be specified as readable, writable, or executable (or any combination of the three) to three groups - the owner of the file, members of the single group mentioned in the file’s permissions, and any user of the system at all. This model of access control enables a file to enforce (through kernel-defined policy and the filesystem driver itself) exactly how visible and ‘touchable’ it is to anyone sharing a system. The notable exception to file access controls is the superuser; while ordinarily the owner of a file has powers over the permission bits of a file they own, the superuser in most standard Linux control models is empowered with unfettered access to the system and can ignore, at discretion, permission requirements. The superuser can modify any file, including that file’s permissions, regardless of user or group ownership, which is more-or-less necessary to maintain a system.

The second thing I’d like to mention is the netfilter framework, or more specifically the iptables system. Iptables’ game is packet filtering and manipulation at specific points in their routing, enabling a software firewall of sorts (although iptables can do more than just function as a firewall, but that’s outside of the scope of this post). Iptables compiles into the Linux kernel, and most package-managed distributions provide some variation on arno-iptables-firewall, which is a script that enables an indirect, fairly simple method of leveraging iptables’ firewalling capabilities; traffic is allowed or denied on the basis of predefined allowed ports.

Second-to-last, we have the Linux Unified Key system. LUKS uses a prepended header that contains meta-information about an encrypted volume or block device, and works with the dm-crypt module to provide transparent access to encrypted volumes. LUKS fulfils goals of portability and usability through its use of standardization, backup-able headers, and keyslots. Standardization allows a LUKS device to be used anywhere LUKS is supported, header backups enable volumes what would otherwise be lost to be restored without writing or reading more than a few megabytes of data (likely closer to a few KB), and the use of keyslots allow multiple passhprases and easy passphrase assignment/revocation while isolating the master passphrase of a volume. Using a LUKS device is as easy as decrypting it with your passphrase, which creates a usable virtual block device that manages writing to and reading from the volume, and ‘destroying’ a LUKS device is as easy as writing over the first few megabytes of the physical volume or partition with random values, eradicating the header and rendering it functionally unreadable save to those who would waste too much time on it.

Lastly, I’d like to mention two options that can be specified before compiling a kernel (not necessarily just Linux, on this one), namely strong stack protection (a ‘canary’, if you will) and address space layout randomization. GCC’s stack protection uses a randomly-selected machine word on top of a stack for the purpose of detecting overflow; operations on the stack trigger a comparison between the value of the canary on the stack and the known value of that canary (or in other implementations, the entropy used to generate the canary). If they differ, that is an indication that something has gone wrong. Address space layout randomization accomplishes exactly what it sounds like, with the IEEE stating that “ASLR works by randomizing the offset of key program segments in virtual memory, making it difficult for an attacker to derive the addresses of specific code objects and consequently redirect the control flow to this code.” If you deign to read through the sources, you will see that this is not without its flaws (although unfortunately, the IEEE chooses to paywall).

Sources and Extra Reading:

https://www.linux.com/learn/overview-linux-kernel-security-features

https://www.booleanworld.com/depth-guide-iptables-linux-firewall/

https://gitlab.com/cryptsetup/cryptsetup

https://wiki.osdev.org/Stack_Smashing_Protector

7-Zip 的 RCE 安全性問題

7-Zip 被發現安全性問題 (CVE-2018-10115)：「7-Zip: From Uninitialized Memory to Remote Code Execution」。而在 2018/04/30 推出的 18.05 修正了這個問題：「7-Zip 18.05」。

The vulnerability in RAR unpacking code was fixed (CVE-2018-10115).

除了修正以外，另外也開了 ASLR，對安全性會多一些防禦：

2018-03-06 – Discovery 2018-03-06 – Report 2018-04-14 – MITRE assigned CVE-2018-10115 2018-04-30 – 7-Zip 18.05 released, fixing CVE-2018-10115 and enabling ASLR on…