Windows 8 Release Preview Is Out – Let’s Talk Security

I could take screenshots and do a full review of the Windows 8 OS but some other blog that gets paid to do reviews would just do it better so I’ll stick to what this blog is for – security.

Windows 8 has officially been released as a Release Preview, meaning that just about everything you see in this RP is what you’ll see in the final release. The biggest changes in Windows 8 are pretty surface – the highlight is an entirely new Metro UI, which features a full screen start page and various other major UI changes. There are also some big changes under the hood – Windows 8 is a lighter, faster OS than 7 with lower RAM usage and improved multicore support. And then there’s security…

ASLR

Address Space Layout Randomization (ASLR) is a mitigation technique first designed by PaX foundation. The idea is to randomize a programs address space (the range of virtually memory addresses that make up a process) in order to prevent Return Oriented Programming (a technique used to bypass Data Execution Prevention.) Essentially, because the attacker does not know where areas of the address space are they are unable to make use of that address space in a way that would otherwise allow further compromise of the system.

ASLR relies on the attacker not being able to guess the location of address space. They only have three real options (in terms of defeating ASLR):

1) Find part of the address space that isn’t ASLR enabled

2) Make use of information leaks

3) Bruteforce through the addresses

Windows 8 attempts to directly address (1) and (3.)

/FORCEASLR

In Windows 7- if I run a program like Firefox*, which is ASLR enabled but I use Norton Toolbar, which isn’t ASLR enabled I basically defeat the purpose of ASLR because there’s a predictable address. Windows 8 address this with /FORCEASLR, a compile time flag that will force the entire address space to be ASLR enabled (oversimplification, not entirely true, good enough.)

The benefits are obvious, simply using the /FORCEASLR flag in your program means that no other program will significantly degrade the effectiveness of ASLR.

*Firefox has actually solved this issue by forcing toolbars to use ASLR. It’s an outdated example but it works.

Improved Randomness

ASLR effectiveness necessitates the inability of an attacker to guess or predict locations of address space. If there isn’t sufficient address space or there isn’t sufficient entropy the ASLR won’t be effective and an attacker can bruteforce their way to a useful area.

Windows 8 has improved the random number generator and thereby increased randomness in ASLR.

For 32bit systems this is important. Virtual address space on a 32bit system is much smaller than that of a 64bit system (addressable space on 32bit is 2^32 as opposed to 2^64 for 64bit) so bruteforcing is much easier. Improved randomness will make this more difficult – though because of the small address space it’s potentially a lost cause.

Guard Pages

Guard pages work to prevent usable buffer overflows. Developers can make use of Guard Pages to protect areas of address space – when an attacker tries to overflow an area protected by Guard Pages, they’ll end up throwing an exception.

AppContainer

There aren’t a lot of details about AppContainer yet but it looks like Windows is finally getting proper Mandatory Access Control. The ability to apply finely grained application MAC is hugely beneficial both to preventing and limiting exploitation.

Programs don’t have to squeeze into low integrity anymore, they can use whole-process sandboxes (which aren’t actually better, just easier) to segregate themselves from the system.

The jury’s out on this feature. If it’s as powerful as AppArmor I’ll be happy.

Internet Explorer 10 Metro

IE10 Metro runs in the new Metro environment (WinRT) and is sandboxed from the rest of the system.  It also contains a built in Flash player, which Microsoft has integrated into the browser for improved stability, security, and performance. A smart move on Microsoft’s part as the Flash player is still necessary for viewing a ton of the internet and it is also one of the most commonly exploited applications.

Internet Explorer 10 Desktop

The desktop IE10 (and this applies to Metro) will make use of all of the new security mitigations like FORCEASLR and improved randomness. IE10 will also include an “Enhanced Protected Mode”, which implements a further least-privilege mode based on the earlier Protected Mode principals.

The enhanced protected mode continues IE’s least privilege model, which is great and it should prove more difficult to break out of.

Full System Smart Screen

Smart Screen is an application reputation and heuristics system. Previously it was built into IE9 and an NSS Labs report noted it blocking 96+% of malware (there isn’t enough research on the effectiveness, take that report with a golf ball sized chunk of salt.)

SmartScreen in Windows 8 is now system wide. If an application hasn’t been seen before by MS you get a little message saying “hey, we haven’t seen this before, be careful.”

Personally, I don’t like it and I don’t think it will be effective. That’s just me. I don’t think users are capable of making decisions based on information like that and it threw me a ton of “false positives” (not actually FPs as it’s not calling it malware, same principal) so my trust in its opinion of software is seriously diminished. It won’t be effective for the same reason an AV that throws false positives isn’t effective – if I can’t trust the product I’ll never know when it’s right or wrong.

We’ll see.

SecureBoot

SecureBoot is a much reviled feature as everyone though MS would be locking Linux out of Windows 8 hardware. As I posted about earlier Fedora is already working on implementing it. SecureBoot prevents untrusted code from running before the OS. This will prevent rootkits from bypassing full disk encryption and/or wedging themselves deep into the operating system. It’s a great security feature and I think it will be very effective.

Microsoft Security Essentials 

MSE is a widely used antivirus known for being pretty light and quiet – no false positives. It provides pretty decent detection ~50% when out of date and making use only of heuristics (most people probably don’t stay up to date) but I think we can expect that to fall.

As MSE has gotten more popular it’s also started to drop in performance. This is the case with any popular program. The first thing a hacker will do with their payload is test it against a number of antiviruses (automated tools exist for this) and if it passes by MSE but maybe Panda catches it they might release it anyway because MSE still makes up a huge part of market share.

Windows 8 will increase that market share and increase how seriously hackers take bypassing MSE. It’s detection, not preventative, so it’s flawed in that way.

Did I Miss Anything?

I’ve probably forgotten something. If so, leave me a comment.

All in all, Windows 8 is significantly more secure than Windows 7. If AppContainer turns out well it’ll be a huge boon. Even without AppContainer the numerous memory protections added as well as SecureBoot put Windows 8 far ahead of 7 and I’m excited to see Microsoft really taking security seriously. Personally I still feel safer on Ubuntu thanks to being able to do this but it makes Windows feel way more viable and competitive.

Sources:

https://blogs.msdn.com/b/b8/archive/2011/09/15/protecting-you-from-malware.aspx?Redirected=true

https://blogs.msdn.com/b/securitytipstalk/archive/2012/03/27/internet-explorer-10-offers-enhanced-security.aspx?Redirected=true

Compile And Patch Your Own Secure Linux Kernel With PaX and Grsecurity

The reason why Linux and open source will always be more secure than Windows is because you can build advanced security right in. This guide’s going to show you how to do that. I’ll be explaining how to compile your own kernel with PaX and Grsecurity patches. (I’m actually compiling 3.3.6 for myself but this guide covers 3.2.18.)

First let’s explain a few things…

What Is A Kernel?

Well, if you don’t know what a kernel is this guide is probably a bit too advanced but far be it from me to turn you away. The kernel is essentially the core of the operating system. It is the lowest level of software on the system running with the highest rights. Linux runs on “The Linux Kernel” and that kernel is common to all Linux distributions.

What Is PaX?

PaX is a series of patches that can be applied to the Linux kernel. These patches provide functionality and improvements to built in features such as ASLR (Address Space Layout Randomization), which help mitigate and deter exploits.

PaX features can be daunting so for a per-feature explanation see this link. I highly suggest you take a look at these features and research both PaX and Grsecurity so you can fully understand what they provide.

What Is Grsecurity?

Grsecurity is another series of patches that can be applied to the Linux kernel. These patches will allow changes to policy, provide a tool for RBAC, and add new policies. Grsecurity and PaX are built to work together and reinforce one another.

Why Are We Doing This?

Well, to get the most secure system that you can possibly get you’re going to want to start compiling your own kernel. The kernel is, for various reasons, where security belongs (more on this in future posts.) Now, on a default install of some distro like, say, Ubuntu you’re fairly secure and the tools already provided can be used to really lock the system down (think AppArmor) but if you’re looking to secure your system against sophisticated and targeted attacks PAX and Grsecurity are the way to go.

Keep in mind that the settings I use are for my own system. A server would be able to use more settings because it wouldn’t have to worry about, for example, the sound working.

You will also need to do this for new updates from kernel.org in order to get the latest security patches, among other things. Not even Grsecurity will keep an unpatched system safe.

So, since we’re done with the intro…

Setting Up Our System

Before we even download source code we need to make sure we have everything necessary to actually compile and configure our kernel. Let’s start by installing some software: (I’ll assume sudo/root for this guide.)

# apt-get install patch bin86 kernel-package build-essential libncurses5-dev gcc-*-plugin-dev

That’s (hopefully) everything you need to compile, package, and configure the kernel. (You may need to install gcc and plugins.)

Now let’s set up a working folder and cd to it.

# mkdir /usr/src/linux/

# cd /usr/src/linux/

That’s it for now.

Downloading The Linux Kernel And Patches

In this example I’ll be using the Linux Kernel 3.2.18 (the same steps will work for any kernel, just change the patches) and the Grsecurity patch that goes along with it. I’m assuming you’re still in /usr/src/linux/.

# wget https://grsecurity.net/stable/grsecurity-2.9-3.2.18-201205301835.patch

# wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.18.tar.bz2

Once the download has completed you can extract linux-3.2.18.tar.bz2 to ./linux-3.2.18.

Patching The Kernel

This part is fairly simple, move to your new linux-3.2.18 folder and patch.

# cd ./linux-3.2.18

# patch -p1 < /usr/src/linux/grsecurity-2.9-3.2.18-201205301835.patch

This should patch the kernel without any interaction necessary.

Configuring The Kernel

(note: I am taking screenshots of a 3.3.6 kernel with my own configuration, yours may vary. Once size does not fit all – do research!)

#make menuconfig

You’ll be brought to this screen:

Note: If you want to enable KERNEXEC you must go to Processor Features and disable Xen/Paravirtualization.

Navigate (arrow keys) to Security Options and hit ‘Enter’ and…:

Configuring Grsecurity:

As you can see there are many options here. You can use preconfigured options (Low, Medium, High) or, as I suggest, Custom.

The following settings are suggestions that work for me. They can make or break systems depending on usage. A server might need completely different settings, for example. You’ll probably be compiling a few kernels just to see what breaks when.

Memory Protections:

[*] Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port
[  ] Disable privileged I/O
[*] Harden ASLR against information leaks and entropy reduction
[*] Deter exploit bruteforcing
[*] Harden module auto-loading
[*] Hide kernel symbols
[*] Active kernel exploit response

Role Based Access Control (RBAC): I’ll post later about configuring RBAC.

[  ] Disable RBAC system
[*] Hide kernel processes
(3) Maximum tries before password lockout
(30) Time to wait after max password tries, in seconds

Filesystem Protections:

[*] Proc restrictions
[*] Restrict /proc to user only
[*] Additional restrictions
[*] Linking restrictions
[*] FIFO restrictions
[  ] Sysfs/debugfs restriction     -Breaks Sound on Ubuntu
[  ] Runtime read-only mount protection   -For servers, not users.
[*] Chroot jail restrictions
[*] Deny mounts
[*] Deny double-chroots

[*] Deny pivot_root in chroot

[*] Enforce chdir(“/”) on all chroots
[*] Deny (f)chmod +s
[*] Deny fchdir out of chroot
[*] Deny mknod
[*] Deny shmat() out of chroot
[*] Deny access to abstract AF_UNIX sockets out of chroot
[*] Protect outside processes
[*] Restrict priority changes
[*] Deny sysctl writes

[*] Capability restrictions

Kernel Auditing:

Your choice, this is more useful for servers. As a user I don’t need any of this.

Executable Protections:

[*] Dmesg(8) restriction
[*] Deter ptrace-based process snooping
[*] Require read access to ptrace sensitive binaries
[*] Enforce consistent multithreaded privileges
[*] Trusted Path Execution (TPE)
[*] Partially restrict all non-root users -This is one option that I use. It may break things and it’s not a critical feature so you may consider removing it.

Network Protections:

[*] Larger entropy pools
[*] TCP/UDP blackhole and LAST_ACK DoS prevention
[  ] Socket restrictions

SysCtl Support:

[  ] Sysctl support
[  ] Turn on features by default

Configuring PAX:

As with Grsecurity we’re presented with quite a few options. PAX settings can very easily break things so my settings will likely vary from what your settings could be. I will note specific areas where there are known conflicts.

For details on PaX features see this link.

PaX Control:

[  ] Support soft mode By leaving this off we have PaX system wide.
[  ] Use legacy ELF header marking
[  ] Use ELF program header marking
[  ] Use filesystem extended attributes marking

Non-Executable Pages:

[*] Enforce non-executable pages
[*] Paging based non-executable pages
[*] Emulate trampolines
[*] Restrict mprotect() This will break X.
[  ] Use legacy/compat protection demoting (read help)
[  ] Allow ELF text relocations (read help)

[*] Enforce non-executable kernel pages (Requires  you disabled Xen)
Return Address Instrumentation Method (bts) —>

Address Space Layout Randomization:

[*] Address Space Layout Randomization
[*] Randomize kernel stack base
[*] Randomize user stack base
[*] Randomize mmap() base

Miscellaneous Hardening Features: (Note: Users of ATI SPUs must use my settings here. Users with other GPUs should enable all ** settings.)

[*] Sanitize all freed memory
[*] Sanitize kernel stack
[*] Prevent various kernel object reference counter overflows  **
[*] Harden heap object copies between kernel and userland  **
[*] Prevent various integer overflows in function size parameters

**As of version 12.8 the closed source ATI FGLRX drivers are compatible with the above. Earlier versions will NOT work.

Other Security Settings

Exit your PaX options and go back to the security settings.

Set ” Low address space for LSM to protect from user allocation” to 65536 or 32768:

This is the portion of low virtual memory which should be protected
from userspace allocation. Keeping a user from writing to low pages
can help reduce the impact of kernel NULL pointer bugs.

For most ia64, ppc64 and x86 users with lots of address space
a value of 65536 is reasonable and should cause no problems.
On arm and other archs it should not be higher than 32768.
Programs which use vm86 functionality or have some need to map
this low address space will need the permission specific to the
systems running LSM.

Time To Compile And Install

(Note: You may want to see the last section ‘Other Tips’ before you compile.)

# make-kpkg clean

# make-kpkg --initrd --append-to-version "grsec1.0" kernel_image

The above command might give you an error in which case you’ll need to type it out. It’s a wordpress issue where it combines the –‘s.

Compiling will take a while. Probably a half hour, potentially multiple hours depending on the hardware. When you’re done there will be a package in /usr/src/linux.

# cd /usr/src/linux

# dpkg -i ./<name.of.deb>

Reboot into the new kernel and that’s it.

It’s a lot of work to set it up but it should only take you a few minutes after the first time. Compiling is what takes the longest but it can be done in the background.

If something breaks just boot into the last kernel you used. Simple.

Other Tips

Since you’re taking the time to compile this thing you may as well get the most out of it. I suggest you go through the settings and disable any drivers not related/ enable or disable features.

You should also open /usr/src/linux/linux-3.2.18/makefile and find the line:

# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments

And have the following line as: (add the -march=native -pipe -mtune=native)

KBUILD_CPPFLAGS += $(KCPPFLAGS) -march=native -pipe -mtune=native

pipe will speed up compile time significantly for systems with lots of RAM. march=native will optimize the kernel for your specific CPU. Don’t use -march=native if you are compiling for another system with a different CPU (same for mtune).

Take the time to disable drivers that you won’t use. It’ll speed up compile time and produce a smaller kernel.

Highlights

The highlights of this new kernel are:

1) Improved ASLR

2) RBAC

3) Hardened Chroots (if you use Chromium or Google Chrome the sandbox makes use of Chroots so you’ve just made it more secure.)

4) Exploit bruteforcing is much harder

5) A generally more secure system with stricter policies and checks

6) Optimized kernel if you followed the “notes.”

This was a long post so if I’ve left anything out or misrepresented something leave a comment and let me know. RBAC is worth its own full post so I’ll get to that later (setting it up on any user-oriented OS is difficult.) For now you can see this wiki page to learn how to set RBAC up, but it’s not so simple.

Sources:

http://www.howtoforge.com/hardening-the-linux-kernel-with-grsecurity-debian

http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml

https://en.wikibooks.org/wiki/Grsecurity/Print_version

EMET v3.0 – What’s New and How To Set It Up

Microsoft has released version 3.0 of EMET (Enhanced Mitigation Experience Toolkit), a must-have security tool for Windows. To summarize my previous post on EMET, it is a lightweight exploit mitigation tookit that forces programs to make use of modern security techniques – simply put it makes programs more secure. This guide will show you how to set EMET up to secure your Windows system without infringing on your program compatibility. I highly recommend you follow this guide and set EMET up accordingly. I’ve included screenshots to make this guide as clear as possible – setup for 3.0 is just a few minutes.

The major changes in EMET 3.0 are the new pre-made profiles, which make setup easier, and the notifier. EMET will now give a notification when it detects an exploit and you can read about the new pre-made profiles later down the page. You can disable the notifier through msconfig.exe or exit it by clicking the EMET icon in your system tray. I suggest you keep it on unless you’re running on a very old system.

EMET has two main interfaces: one to deal with system wide settings and one to deal with application specific settings.

System Settings:

When you open up EMET you’ll see:

Click “Configure System” and you’ll be brought here: (Your settings will look different)

My suggested configuration is:

DEP: Always On

SEHOP: Always On

ASLR: Opt In

What this means is that all programs will be forced to use DEP and SEHOP and programs have the ability to opt into using ASLR. If you are noticing instability you can change the DEP setting to “Opt-Out” or back to “Opt-In” but I strongly recommend you try Always On first. SEHOP can only be set to “Opt-Out” on Windows 7.

That’s all it takes to set EMET up system wide. (And a system reboot, which you can do after following the rest of this guide.)

Note: ATI Drivers 12.6+ are now ASLR compatible. You may want to give ASLR Always On a try!

Application Specific Settings:

EMET 3.0 makes securing individual programs incredibly easy. Click the “Configure Apps” button on the bottom right of the EMET GUI.

You’ll see this:

Go to File -> Import and navigate to /Program Files(86)/EMET/Deployment/Protection Profiles/all.xml and open it through EMET.

This will add a large list of programs, already configured, to your EMET list. You can change this up if you like but right away your system is much more secure. The default settings seem to cover the most important areas.

If you want to add another program just click “Add” and navigate to the .exe.

The highlight of the preconfigured .xml is that all Java executable files as well as your browser and browser plugins are configured to use EMET. These are the most commonly exploited programs and hardening them is a critical step in securing your system.

You may receive a notification from the EMET Notifier. A new feature to 3.0 that lets you know which security mitigation was just used to prevent an exploit.

 

 

 

That’s all there is to setting up EMET. This should take just a few minutes (including time to download) and it’s the first step to securing Windows. I hope this guide helped.

Tip: If you notice an EMET’d program acting out try disabling EAF. It can cause issues.

You can download EMET from:

https://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx?Redirected=true

Note:

It is worth stating that just because you use EMET does not mean you can forego patching. While EMET is an incredible tool for securing Windows it is not a silver bullet, you must keep your system up to date.

Sources:

http://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx

EMET – A Windows Security Tool That Everyone Should Use

Techniques like ASLR and DEP have made exploitation of modern software more difficult. And yet many programs still don’t make use of them. Why? Well, sometimes it’s a matter of compatibility but very often it’s simply a matter of the developer not knowing or not caring enough to implement them.

EMET sets out to fix this.

There are very few programs that I think belong on every single computer. EMET is one of those few.

What is it?

EMET is the Enhanced Mitigation Experience Toolkit and it’s pretty damn cool. The goal of EMET is to prevent programs from being exploited by forcing them to make use of modern mitigation techniques (EAF, SEHOP, ASLR, DEP, HeapSpray, Bottom Up Randomization.)

The Good

EMET attempts to bring insecure programs like Java (which is the most exploited piece of software for Windows users) up to speed in terms of security. By running Java with EMET you can prevent a ton of exploits that would have otherwise led to infection. You can also run your browser with EMET to prevent Flash/ browser exploits.

EMET also uses virtually no resources. EMET.dll is something like 44kb and that’s all that’s loaded into programs. The mitigation techniques should have a negligible effect on performance as well.

Compatibility is easy to maintain as EMET can be used on a per-program basis. I suggest that you run your PDF viewer and Java with EMET and consider running your browser as well.

Windows XP users should be downloading EMET as soon as possible. XP doesn’t have any form of ASLR but EMET will provide EAF, which is another ROP mitigation (though less effective.)

The Bad

EMET is not a replacement for an antivirus. It offers absolutely no detection of malware or malicious activity – its only goal is to prevent exploitation.

Even with all of those mitigation techniques there are ways around them; DEP and ASLR just don’t apply to every situation ie: JIT Spraying, which needs a whole separate class of mitigation. EMET drives up the cost of exploit, it doesn’t eliminate the threat.

Some of the techniques like EAF and HeapSpray are also easily bypassed, they’re more for defeating automated attacks, which is still valuable since that’s what the average user will come across.

There are potential compatibility issues with EMET. Very old programs can’t handle DEP and they’ll potentially break even if you just install EMET. It sucks. I suggest you contact the developer and remove EMET in the meantime.

It should be plain to see why EMET is such a significant security tool. Forcing horribly insecure programs like Java to start acting like modern software is probably the most important first step in securing Windows. EMET is a must have, whether you’re on XP, Vista, or 7.

I’ll be posting a guide with screenshots on how to set up EMET very soon.

Grab EMET Here:

https://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx?Redirected=true