Hacking & Security
Some months ago, I started reverse engineering and investigating the security posture of the Adobe Type Manager Font Driver (ATMFD.DLL) module, which provides support for Type 1 and OpenType fonts in the Windows kernel since Windows NT 4.0, and remains there up to this day in Windows 8.1. Specifically, I focused on the handling of so-called “Charstrings”, which are essentially binary encoded PostScript programs with a dedicated set of instructions and a specific execution environment, responsible for drawing the shape of each glyph at a particular point size. It didn’t take long to notice several important points:
- The overall code quality of the Charstring interpreter function in ATMFD.DLL was badly low, with some bugs being clearly visible in the code at first glance. This implied that (surprisingly, considering the seemingly large amount of attention received from the security community) I entered a completely unexplored territory that others haven’t delved into, or at least publicly.
- The kernel module used the same interpreter for both Type 1 (Type 1 fonts) and Type 2 (OpenType/CFF fonts) Charstrings, and supported every single feature that has ever been part of the specification, and plenty of undocumented ones as well – bloating the size of the function to more than 20kB (!) on the x86 platform.
- As a result of historically strong collaboration between vendors in the early days of digital font development (the 80’s and mostly 90’s), various modern font engines have a common ancestor in Adobe’s implementation of Type 1 / OpenType fonts, including:
- Windows GDI (i.e. ATMFD.DLL in the Windows kernel),
- Adobe Reader (i.e. the CoolType library),
- Microsoft DirectWrite (a library used by Internet Explorer, Google Chrome, Mozilla Firefox etc.),
- Windows Presentation Foundation.
The above observations led me to believe that the code could be affected by one or more critical vulnerabilities, and that some of those vulnerabilities could be shared across multiple widespread desktop products, additionally elevating the potential impact of any such discovery. After several weeks of reverse engineering and auditing the interpreter for vulnerabilities, I have ended up with multiple low to critical severity issues, with most of the serious ones reproducing in more than one font engine. I subsequently reported all of my discoveries to the respective vendors (Microsoft and Adobe), which fixed the bugs in security bulletins MS15-021 (March), APSB15-10 (May) and MS15-044 (May). A quick summary of the research results is shown below, with links pointing to the corresponding google-security-research bug tracker entries, containing reports with detailed analysis of the vulnerabilities together with Proof of Concept files, as they were provided to the vendors:Microsoft Windows (ATMFD) Adobe Reader (CoolType) DirectWrite Windows Presentation Foundation Unlimited Charstring execution CVE-2015-0074 – – – Out-of-bounds reads from the Charstring stream CVE-2015-0087 CVE-2015-3095 – – Off-by-x out-of-bounds reads/writes relative to the operand stack CVE-2015-0088 – – – Memory disclosure via uninitialized transient array CVE-2015-0089 CVE-2015-3049 CVE-2015-1670 CVE-2015-1670 Read/write-what-where in LOAD and STORE operators CVE-2015-0090 – – – Buffer overflow in Counter Control Hints CVE-2015-0091 CVE-2015-3050 – – Buffer underflow due to integer overflow in STOREWV CVE-2015-0092 CVE-2015-3051 – – Unlimited out-of-bounds stack manipulation via BLEND operator CVE-2015-0093 CVE-2015-3052 – –
While many of the above issues had the potential to be usable in the context of remote code execution (Adobe Reader, Windows kernel) or elevation of privileges (Windows kernel) attacks, one particular vulnerability stood out from the others, as it provided a specially crafted font with the ability to operate on any data on the thread’s stack with all instructions available in the Type 1 / Type 2 Charstring instruction set (including arithmetic, logic, conditional, and other instructions). In other words, one could reliably generate a full ROP chain on the stack within the PostScript program, with no external interaction other than loading the font in the first place.
The extremely powerful primitive provided by the vulnerability, together with the fact that it affected all supported versions of both Adobe Reader and Microsoft Windows (32-bit) – thus making it possible to create an exploit chain leading to a full system compromise with just a single bug – makes it one of the most interesting security issues I have discovered so far. Considering that 64-bit builds of Windows were not affected by that particular bug, I also devised a x64 way to achieve reliable elevation of privileges using another Charstring vulnerability (CVE-2015-0090) found during the research, which also adheres to the “100% reliability” and “all mitigations bypassed” philosophy. Since the overall exploitation process was also quite challenging and required the use of several interesting tricks, I decided to discuss it at the REcon security conference in Montreal in a talk called “One font vulnerability to rule them all: A story of cross-software ownage, shared codebases and advanced exploitation”. As I presented the research two days ago, I am now publishing the corresponding slide deck:
Below you can see videos showing successful exploitation of Adobe Reader 11.0.10 using the BLEND vulnerability (CVE-2015-3052), accompanied by sandbox escapes via ATMFD.DLL in the Windows Kernel, using again the BLEND vulnerability on x86 builds (CVE-2015-0093) and a “Registry Object” vulnerability on x64 builds (CVE-2015-0090).
If you are interested in font vulnerability research, be sure to keep an eye out on this and the Google Project Zero blogs, as further technical posts and/or whitepapers regarding this effort will be published there in the near future.
Adobe Systems Inc. today released an emergency update to fix a dangerous security hole in its widely-installed Flash Player browser plugin. The company warned that the vulnerability is already being exploited in targeted attacks, and urged users to update the program as quickly as possible.
In an advisory issued Tuesday morning, Adobe said the latest version of Flash — v. 188.8.131.52 on Windows and Mac OS X — fixes a critical flaw (CVE-2015-3113) that is being actively exploited in “limited, targeted attacks.” The company said systems running Internet Explorer for Windows 7 and below, as well as Firefox on Windows XP, are known targets of these exploits.
If you’re unsure whether your browser has Flash installed or what version it may be running, browse to this link. Adobe Flash Player installed with Google Chrome, as well as Internet Explorer on Windows 8.x, should automatically update to the latest version. To force the installation of an available update on Chrome, click the triple bar icon to the right of the address bar, select “About Google” Chrome, click the apply update button and restart the browser.
The most recent versions of Flash should be available from the Flash home page, but beware potentially unwanted add-ons, like McAfee Security Scan. To avoid this, uncheck the pre-checked box before downloading, or grab your OS-specific Flash download from here. Windows users who browse the Web with anything other than Internet Explorer may need to apply this patch twice, once with IE and again using the alternative browser (Firefox, Opera, e.g.)
In lieu of patching Flash Player yet again, it might be worth considering whether you really need to keep Flash Player installed at all. In a happy coincidence, earlier today I published a piece about my experience going a month without having Flash Player installed. The result? I hardly missed it at all.
Despite reaching its official end of life over a year ago, Microsoft's Windows XP is still bringing the company some significant revenue—largely because Department of Defense and government customers can't seem to get rid of it. And the Navy is one of Microsoft's best custom-support customers.
The US Navy's Space and Naval Warfare Systems Command (SPAWAR) has closed a $9.1 million contract extension with Microsoft that the agency originally announced in April to further extend custom support for the venerable Windows XP operating system, as well as the Office 2003 suite and Exchange 2003 e-mail. According to a Navy contracting announcement, "Across the United States Navy, approximately 100,000 workstations currently use these applications. Support for this software can no longer be obtained under existing agreements with Microsoft because the software has reached the end of maintenance period."
The renewal, according to SPAWAR officials, will buy the Navy "time to migrate from its existing reliance on the expiring product versions to newer product versions approved for use in Ashore and Afloat networks, and will provide hotfixes to minimize risks while ensuring support and sustainability of deployed capabilities." Many of the systems are in shipboard administrative networks that have not been available for extended periods of maintenance; the Navy is also playing catch-up on its land-based network upgrades as the result of the long delays in the service's Next Generation Network (NGEN) contract—the follow-up to the outsourced Navy and Marine Corps Intranet (NMCI).
In the second edition of our n00bs CTF Labs, we’ve created 13 small challenges to test your web app hacking skills. The challenges are based on common vulnerabilities (XXS, code injection, inadequate redirect functions ect.) as well as older and less frequently seen vulnerabilities such as Data Validation; Parameter Delimiter. Each level has a bounty of $100, you […]
I’ve spent the better part of the last month running a little experiment to see how much I would miss Adobe‘s buggy and insecure Flash Player software if I removed it from my systems altogether. Turns out, not so much.
Browser plugins are favorite targets for malware and miscreants because they are generally full of unpatched or undocumented security holes that cybercrooks can use to seize complete control over vulnerable systems. The Flash Player plugin is a stellar example of this: It is among the most widely used browser plugins, and it requires monthly patching (if not more frequently).
It’s also not uncommon for Adobe to release emergency fixes for the software to patch flaws that bad guys started exploiting before Adobe even knew about the bugs. This happened most recently in February 2015, and twice the month prior. Adobe also shipped out-of-band Flash fixes in December and November 2014.
Update, 11:30 a.m. ET: Oddly enough, Adobe just minutes ago released an out-of-band patch to fix a zero-day flaw in Flash.
Time was, Oracle’s Java plugin was the favorite target of exploit kits, software tools made to be stitched into hacked or malicious sites and foist on visiting browsers a kitchen sink of exploits for various plugin vulnerabilities. Lately, however, it seems to pendulum has swung back in favor of exploits for Flash Player. A popular exploit kit known as Angler, for example, bundled a new exploit for a Flash vulnerability just three days after Adobe fixed it in April 2015.
So, rather than continue the patch madness and keep this insecure software installed, I decided to the pull the…er…plugin. I tend to (ab)use different browsers for different tasks, and so uninstalling the plugin was almost as simple as uninstalling Flash, except with Chrome, which bundles its own version of Flash Player. Fear not: disabling Flash in Chrome is simple enough. On a Windows, Mac, Linux or Chrome OS installation of Chrome, type “chrome:plugins” into the address bar, and on the Plug-ins page look for the “Flash” listing: To disable Flash, click the disable link (to re-enable it, click “enable”).
In almost 30 days, I only ran into just two instances where I encountered a site hosting a video that I absolutely needed to watch and that required Flash (an instructional video for a home gym that I could find nowhere else, and a live-streamed legislative hearing). For these, I opted to cheat and load the content into a Flash-enabled browser inside of a Linux virtual machine I have running inside of VirtualBox. In hindsight, it probably would have been easier simply to temporarily re-enable Flash in Chrome, and then disable it again until the need arose.
If you decide that removing Flash altogether or disabling it until needed is impractical, there are in-between solutions. Script-blocking applications like Noscript and ScriptSafe are useful in blocking Flash content, but script blockers can be challenging for many users to handle.
Another approach is click-to-play, which is a feature available for most browsers (except IE, sadly) that blocks Flash content from loading by default, replacing the content on Web sites with a blank box. With click-to-play, users who wish to view the blocked content need only click the boxes to enable Flash content inside of them (click-to-play also blocks Java applets from loading by default).
Windows users who decide to keep Flash installed and/or enabled also should take full advantage of the Enhanced Mitigation Experience Toolkit (EMET), a free tool from Microsoft that can help Windows users beef up the security of third-party applications.
In this article series, we will learn about a famous Linux family of malware known as MOOSE, which is used to steal unencrypted traffic over the wire and infect other devices automatically. This malware steals HTTP cookies and performs non-legitimate “likes,” “views” etc. on social networking sites. In the complete article series, we will learn […]