SOLDIERX.COM Nobody Can Stop Information Insemination

It takes a lot to run a project like HardenedBSD. We're grateful for SoldierX's sponsorship. In 2014, we asked the community for help in funding a development server. The community responded quickly and our server was fully-funded within a short amount of time. That server is now being put to great use as our package building server. We appreciate all the help everyone has given us to date.

We would like to ask the community today for further donations. Our target is $7,000 USD. The funds will go towards hardware updates, hosting requirements, and potentially setting up a not-for-profit (501(c)(3)) organization so further donations will become tax-deductible.

If you'd like to donate, please donate via PayPal at address [email protected]. We also accept BitCoin at address 1FmbSRvZK4yC1b6ajeZWSvYXV2nmvwdWQq. If you donate and wish your name to be added to the Donors page, please drop an email to [email protected]. Every donation counts and is appreciated, even donations as small as $1.00 USD.

Over the July 4th weekend, we implemented randomization of the VDSO (Virtual Dynamic Shared Object). The VDSO is a spot in memory that is shared between the kernel and userland memory. It contains the signal trampoline and time-related code (like gettimeofday(2)). Even though the amount of code is small in the VDSO, it could still theoretically be used to generate ROP gadgets. Removing that piece of determinism makes generating ROP gadgets based on code in the VDSO more difficult. Randomizing the VDSO was the last piece of the address space to randomize.

Now that VDSO randomization is implemented, our ASLR implementation is now complete. You'll notice a new sysctl(8): hardening.pax.aslr.vdso_len. That controls the amount of entropy applied to the VDSO base. Our version of ASLR is the strongest form ever implemented in any BSD operating system.

Our ASLR implementation features:

1. Execution base randomization of Position-Independent Executables (PIEs)
2. Full stack randomization in addition to a random stack gap
3. RTLD base randomization
4. mmap randomization
5. VDSO randomization
6. Shared object load order randomization

You will still see further improvements. We are looking into making our shared object load order randomization more efficient with help from Michael Zandi. We need to update our aslr(4) manpage. We need to clarify some of the inline comments. These improvements are mostly cosmetic and result in no functionality changes.

When we first implemented ASLR for FreeBSD, we implemented the stack randomization portion as a random gap. This means that the base address for the stack remained constant, but where applications started utilizing the stack would change randomly. We have now implemented true stack randomization. The base address for the stack is now randomized. We still utilize a random stack gap on top of true stack randomization to provide further entropy and security. This means that we can effectively achieve 42 bits of entropy for the stack. Compare that to OpenBSD, which utilizes only a gap with 14 bits of entropy. This change breaks both ABI and API and we have bumped the HardenedBSD version up to 26 with this change. We will be doing a new package build to ensure packages are up-to-date with this change.

You can find the git commit here. For more details about how the PaX Team recommends doing stack randomization, take a look here.

Due to some changes to google voice, RoboAmp 1.00 (public Defcon 22 release) stopped working. RoboAmp has been updated to adapt to these changes, as well as a few other minor changes. You can get the new version here. If you would like to see more changes to RoboAmp or any of our other SX Labs releases, please drop by for our IRC meeting tomorrow at 4 PM EST.

Just a heads up to all, we are working to make the site faster. We've already made some database changes that should have increased the site speed quite a bit. We hope these optimizations will increase the current usage of the forums. We also have plans to move to newer hardware, but we're still working those details out due to our limited budget. Please contact me if you notice any particularly slow areas of the site that you'd like to be faster.

For those who are VIP, I have released 0.1.7 and it has now been made available in the SX Labs section of the site for testing.

Also, on May 1st at 6 PM EST I will be doing a meeting to discuss the OFACE Roadmap in IRC. I highly encourage VIP members to attend as well as we want to hear what you think of the Roadmap we are planning.

Unfortunately shortly after his induction into the SX Crew, Shinobi has gone missing. As a result, n0 has been stepping up to fill his shoes. The high council has finally finished discussing meeting issues, crew issues, and project issues. As a result, we will be having a major IRC meeting tomorrow (04-16-2015) from noon to two (12:00-14:00) EST. We hope that all the crew will be able to attend, as well as many of our more committed community members. If you're a VIP member, please check out the forums for news on some major releases

We're excited to announce the release of secadm version 0.2! We've been working hard on a new star feature: Integriforce.

You can download secadm 0.2 here and the GPG signature here. It was signed with Shawn Webb's GPG key with fingerprint 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE.

Change Log:

• New feature: Integriforce. executable file integrity through hash checking and enforcement
• Fix issue linking with prior versions of secadm
• Fix typos
• Various cleanups

Announcing Integriforce

This feature provides executable file integrity enforcement. If a rule exists for a given file, that file's hash as defined in the rule is matched against the hash of the file. If the hashes don't match, execution may be disallowed, depending on the configuration settings. Integriforce is an optional, but powerful, feature. Integriforce currently supports SHA1 and SHA256. Both executables and shared libraries are supported. Please note that files that are under Integriforce management cannot be modified or deleted. The ruleset will need to be flushed prior to modifying or deleting the file.

When we did our call for testing (and thank you to those who tested!), only executable files were checked, not their dependencies (shared objects). With HardenedBSD v18 (sysctl hardening.version) and secadm 0.2, we now support checking the dependencies. This required a change in the runtime linker (also known as the RTLD) that calls into Integriforce if it is available. Additionally, there is a new kernel feature sysctl exposed, kern.features.integriforce.

Throughout the years, we have had a number of people ask us where we stood on religion. With religion being a hot topic in the news lately, we've been pushed more and more on our stance. This has prompted a couple of us here to actually think about it and come to a conclusion that the closest thing to religion that many of us have is through our work. If we gave that answer to somebody though, they wouldn't consider it valid. Well.... until now.

In accordance with the recently passed Religious Freedom Restoration Act in Indiana, we have decided to file the appropriate paperwork with the state to create the Disciples of 0day Inc. which will be an organization which worships by furthering our knowledge and understanding with technology. Also, due to how the RFRA works in Indiana, some aspects of the DMCA cannot be enforced against active members due how it conflicts and potentially discriminates against our religious practices.

Our primary doctrine is to further your knowledge and understanding in various aspects of technology which will include hardware modification, bypassing unnecessary protection on privately owned hardware, understanding exploits, and creating effective proofs of concept for exploits. As for who can join, our organization will welcome anybody regardless of race, gender, and/or sexual orientation as we feel all would benefit from our doctrine.

So if you worship the almighty 0day, please reach out to us and join the Disciples of 0day today! Attached to this post are a few motivational pictures (including our new church logo).

For the past few weeks, I've been working on a new feature for HardenedBSD's secadm project. secadm is short for Security Administration and is built to control the various exploit mitigation features we're developing in HardenedBSD. I'm currently writing a feature I've termed "Integriforce", short for "integrity enforce." It's very similar in concept to NetBSD's Veriexec feature.

In secadm's configuration file, you list the executables you want to make sure verify to a certain hash along with the hash. You can specify two modes: soft or hard. Soft means that execution is allowed even if the hashes don't match, but a warning message is logged. Hard mode disallows execution if the hashes don't match along with logging an error message.

As it stands right now, verification of shared objects an application depends on is not happening. We are investigating how to do that while still giving reasonable performance. One possible solution is to check the hash on every call to open(). We would cache the modified time (mtime) of the file. If the file hasn't been modified since its first hash check, then we already know the state of the file. If the file has changed (mtime differs), then rerun the hash calculation and update the cache. This would be expensive on both the CPU side and the disk side, especially given the mutexes/locks needed to maintain multicore/multiprocessor safety. Now each call to open() would require acquiring at least one lock, possibly two.

We've completed our first milestone and are preparing to release secadm 0.2-rc1 within the next couple weeks. Verifying the integrity of applications using SHA1 and SHA256 are currently supported. The second milestone will be released as secadm version 0.3. That will include ELF binary signing with x509 certificates, similar to how PE files can be signed.