Friday, 21 August 2009

Gentoo hardened overlay update - once again :)

The xake-toolchain overlay has been moved to overlays.gentoo.org and renamed to hardened-overlay and is available now directly using layman! So if you were using layman to track xake-toolchain it's time to update...


# layman -d xake-toolchain
* Successfully deleted overlay "xake-toolchain".

And add:

# layman -a hardened-development
* Running command "/usr/bin/git clone "git://git.overlays.gentoo.org/proj/hardened-development.git" "/usr/local/portage/layman/hardened-development""...
Initialized empty Git repository in /usr/local/portage/layman/hardened-development/.git/
remote: Counting objects: 2180, done.
remote: Compressing objects: 100% (1090/1090), done.
remote: Total 2180 (delta 992), reused 2089 (delta 935)
Receiving objects: 100% (2180/2180), 2.11 MiB | 618 KiB/s, done.
Resolving deltas: 100% (992/992), done.
* Successfully added overlay "hardened-development".

Test case: ;)

# layman -l
* hardened-development [Git ] (git://git.overlays.gentoo.org/proj/hardened-development.git)

Happy compiling! ;]

Friday, 14 August 2009

Gentoo hardened overlay update

Gcc-4.4.1 and gcc-4.3.4 are now in master branch of the xake-toolchain overlay. :) Therefore if you've been using the testing branch you can now switch to master:

~ # cd "/usr/local/portage/layman/xake-toolchain"
x86 xake-toolchain # git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 6 commits, and can be fast-forwarded.
xake-toolchain # layman -S
* Running command "cd "/usr/local/portage/layman/xake-toolchain" && /usr/bin/git pull"...
Updating 7ac8e25..659a4cc
Fast forward
README | 11 +-
eclass/flag-o-matic.eclass | 137 +++-
eclass/hardened-funcs.eclass | 812 -----------------
eclass/toolchain-funcs.eclass | 463 ----------
eclass/toolchain.eclass | 911 ++++++++++++++++++--
sys-boot/grub/Manifest | 2 +-
sys-boot/grub/grub-0.97-r10.ebuild | 17 +-
sys-devel/gcc/Manifest | 25 +-
sys-devel/gcc/gcc-4.3.3-r1.ebuild | 85 --
.../{gcc-4.3.3-r3.ebuild => gcc-4.3.4-r1.ebuild} | 25 +-
.../{gcc-4.3.3-r2.ebuild => gcc-4.4.1-r2.ebuild} | 33 +-
sys-libs/glibc/Manifest | 3 +-
.../2.10/glibc-2.10-hardened-ssp-compat.patch | 168 ++++
sys-libs/glibc/glibc-2.10.1.ebuild | 3 +
sys-libs/libstdc++-v3/ChangeLog | 235 -----
sys-libs/libstdc++-v3/Manifest | 6 -
.../libstdc++-v3/files/compile_with_no-SSP.patch | 11 -
sys-libs/libstdc++-v3/libstdc++-v3-3.3.6-r1.ebuild | 179 ----
sys-libs/libstdc++-v3/metadata.xml | 5 -
19 files changed, 1205 insertions(+), 1926 deletions(-)
delete mode 100644 eclass/hardened-funcs.eclass
delete mode 100644 eclass/toolchain-funcs.eclass
delete mode 100644 sys-devel/gcc/gcc-4.3.3-r1.ebuild
rename sys-devel/gcc/{gcc-4.3.3-r3.ebuild => gcc-4.3.4-r1.ebuild} (75%)
rename sys-devel/gcc/{gcc-4.3.3-r2.ebuild => gcc-4.4.1-r2.ebuild} (72%)
create mode 100644 sys-libs/glibc/files/2.10/glibc-2.10-hardened-ssp-compat.patch
delete mode 100644 sys-libs/libstdc++-v3/ChangeLog
delete mode 100644 sys-libs/libstdc++-v3/Manifest
delete mode 100644 sys-libs/libstdc++-v3/files/compile_with_no-SSP.patch
delete mode 100644 sys-libs/libstdc++-v3/libstdc++-v3-3.3.6-r1.ebuild
delete mode 100644 sys-libs/libstdc++-v3/metadata.xml
*
* Success:
* ------
*
* Successfully synchronized overlay "xake-toolchain".
xake-toolchain #


Thanks guys! :)))

Tuesday, 11 August 2009

gcc-4.4.1-r2 is out!

The hardened overlay has just been updated - with ebuilds for gcc-4.3.4 and gcc-4.4.1-r2. The new ebuild for 4.4.1 includes new espf-0.3.2 patches.

# gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.1-r2/work/gcc-4.4.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-espf --disable-libgomp --enable-cld --disable-libgcj --with-arch=i686 --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.4.1-r2 p1.0, espf-0.3.2'
Thread model: posix
gcc version 4.4.1 (Gentoo Hardened 4.4.1-r2 p1.0, espf-0.3.2)

Thanks to everyone involved in making this happen! :)

New grsecurity test patch for 2.6.30.4

Available here. It fixes a signal handling error which seemed to prevent firefox from running on x86 machine.

Get it now while it's fresh! ;]

Friday, 7 August 2009

64-bit 2.6.30.4-grsec

It seems that bug that stopped latest grsecurity patch to work on 64-bit kernels has been resolved. The latest grsecurity-2.1.14-2.6.30.4-200908051916.patch is working fine for over a day of a standard desktop use - stable enough for me! ;)

# paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux 2.6.30.4-grsec #4 SMP Thu Aug 6 09:57:40 BST 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable stack (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments : Killed
Anonymous mapping randomisation test : 33 bits (guessed)
Heap randomisation test (ET_EXEC) : 40 bits (guessed)
Heap randomisation test (ET_DYN) : 40 bits (guessed)
Main executable randomisation (ET_EXEC) : 32 bits (guessed)
Main executable randomisation (ET_DYN) : 32 bits (guessed)
Shared library randomisation test : 33 bits (guessed)
Stack randomisation test (SEGMEXEC) : No randomisation
Stack randomisation test (PAGEEXEC) : 40 bits (guessed)
Return to function (strcpy) : *** buffer overflow detected ***: rettofunc1 - terminated
rettofunc1: buffer overflow attack in function - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy) : *** buffer overflow detected ***: rettofunc2 - terminated
rettofunc2: buffer overflow attack in function - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (strcpy, RANDEXEC) : *** buffer overflow detected ***: rettofunc1x - terminated
rettofunc1x: buffer overflow attack in function - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy, RANDEXEC) : *** buffer overflow detected ***: rettofunc2x - terminated
rettofunc2x: buffer overflow attack in function - terminated
Report to http://bugs.gentoo.org/
Killed
Executable shared library bss : Killed
Executable shared library data : Killed

Wednesday, 5 August 2009

Kernel 2.6.30.4 with Grsecurity patch

The latest stable patch for the 2.6 branch on the grsecurity.net website is for 2.6.27 kernel and the latest available gentoo hardened-sources ebuild that includes grsecurity is for 2.6.29 but the latest kernel is 2.6.30.4 so... ;)

NOTE: This info applies to a testing version of the grsecurity patch and is very likely to harm your system and eat your hamster (possibly). I wouldn't use it on a production system at all...Also it does not seem to work properly on amd64 architecture at the moment. It didn't work for me on x86_64 but it seems fine on x86. Ya've been warned!

NOTE2: I mainly followed this information which includes much more details about the installation process and Grsecurity and PAX itself. Definitely a recommended reading!

Ok, here we go...first, the kernel sources:

# cd /usr/src
# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.4.tar.bz2
# http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.4.tar.bz2.sign


As recommended on the aforementioned guide, it's always good idea to verify your sources. It doesn't really matter that much if you have downloaded the archive from the main kernel website (unless you don't trust your ISP ;)). Of course someone could plant a backdoor in the source tree before it got packaged, but...anyway! Latest information about kernel signature (and key) can be found here. Verification time! But first the actual key is needed:

# gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E
gpg: requesting key 517D0F0E from hkp server wwwkeys.pgp.net
gpg: key 517D0F0E: public key "Linux Kernel Archives Verification Key " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1

...and verification follows...:

# gpg --verify linux-2.6.30.4.tar.bz2.sign
gpg: Signature made Fri Jul 31 00:13:44 2009 BST using DSA key ID 517D0F0E
gpg: Good signature from "Linux Kernel Archives Verification Key "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E

Looks good...unpack the sources:

# tar jxf linux-2.6.30.4.tar.bz2

And time for patch - including key to verify it of course! ;]

# wget http://grsecurity.net/spender-gpg-key.asc
# wget http://grsecurity.net/test/grsecurity-2.1.14-2.6.30.4-200908041752.patch
# wget http://grsecurity.net/test/grsecurity-2.1.14-2.6.30.4-200908041752.patch.sig

Again - import the key and verify the patch:

# gpg --import spender-gpg-key.asc
gpg: key 4245D46A: public key "Bradley Spengler (spender) " imported
gpg: Total number processed: 1
gpg: imported: 1

# gpg --verify grsecurity-2.1.14-2.6.30.4-200908041752.patch.sig
gpg: Signature made Tue Aug 4 22:56:17 2009 BST using DSA key ID 4245D46A
gpg: Good signature from "Bradley Spengler (spender) "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9F74 393D 7E7F FF3C 6500 E778 9879 B649 4245 D46A

If you already have symlink to linux you need to update it to point to new kernel tree. Or create new one if it doesn't exist:

# ln -s linux-2.6.30.4 linux

Patch the sources and get ready for kernel configuration! ;)

# patch -p0 < ./grsecurity-2.1.14-2.6.30.4-200908041752.patch
# cd linux

You can use your current kernel configuration by copying relevant file that is corresponding with your kernel version from /boot/config-X.X.X to
/usr/src/linux/.config. Alternatively:

# zcat /proc/config.gz > /usr/src/linux/.config

Now the beast itself. Run your favourite kernel configuration variant (make oldconfig ;)) and enable grsecurity along with PAX. Use one of the predefined security levels or just choose custom and read this.

# make menuconfig

I use genkernel wrapper - it creates initramfs automatically that will work with my LUKS encrypted partition:

# genkernel --luks all

Update bootloader to use the new kernel and rewrite MBR -reboot, choose your new kernel and pray! If it have worked:

# uname -srv
Linux 2.6.30.4-grsec #1 SMP Wed Aug 5 15:29:37 BST 2009

And just to be on a safe side:

# paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux 2.6.30.4-grsec #1 SMP Wed Aug 5 15:29:37 BST 2009 i686 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable stack (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments : Killed
Anonymous mapping randomisation test : 17 bits (guessed)
Heap randomisation test (ET_EXEC) : 23 bits (guessed)
Heap randomisation test (ET_DYN) : 23 bits (guessed)
Main executable randomisation (ET_EXEC) : 15 bits (guessed)
Main executable randomisation (ET_DYN) : 15 bits (guessed)
Shared library randomisation test : 17 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : *** buffer overflow detected ***: rettofunc1 - terminated
rettofunc1: buffer overflow attack in function - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy) : *** buffer overflow detected ***: rettofunc2 - terminated
rettofunc2: buffer overflow attack in function - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (strcpy, RANDEXEC) : *** buffer overflow detected ***: rettofunc1x - terminated
rettofunc1x: buffer overflow attack in function - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy, RANDEXEC) : *** buffer overflow detected ***: rettofunc2x - terminated
rettofunc2x: buffer overflow attack in function - terminated
Report to http://bugs.gentoo.org/
Killed
Executable shared library bss : Killed
Executable shared library data : Killed


Yuppie! ;]

Tuesday, 4 August 2009

Using layman to track the hardened overlay

Ok, so manually updating an overlay is boring and cumbersome ;) Well, I mean, instead of doing:

cd /usr/local/toolchain-overlay && git update

You could simply run:

layman -S

Efficiency!

So if you haven't used layman before here's quick step-by-step. First - quite obviously - we need to emerge layman itself:

# emerge -av layman

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] dev-python/pyxml-0.8.4-r2 USE="-doc -examples" 718 kB
[ebuild N ] app-portage/layman-1.2.3 USE="-git -subversion -test" 46 kB

Total: 2 packages (2 new), Size of downloads: 764 kB

Would you like to merge these packages? [Yes/No]

...after few minutes portage kindly informs us what to do next:

* Select an overlay and add it using
* layman -a overlay-name
* If this is the very first overlay you add with layman,
* you need to append the following statement to your
* /etc/make.conf file:
*
* source /usr/local/portage/layman/make.conf
*
* If you modify the 'storage' parameter in the layman
* configuration file (/etc/layman/layman.cfg) you will
* need to adapt the path given above to the new storage
* directory.
* Please add the 'source' statement to make.conf only AFTER
* you added your first overlay. Otherwise portage will fail.

Nice and easy. Here we go:

# layman -o http://github.com/Xake/toolchain-overlay.git/xake-toolchain.xml -fa xake-toolchain
* Running command "/usr/bin/git clone "git://github.com/Xake/toolchain-overlay.git" "/usr/local/portage/layman/xake-toolchain""...
Initialized empty Git repository in /usr/local/portage/layman/xake-toolchain/.git/
remote: Counting objects: 2083, done.
remote: Compressing objects: 100% (1306/1306), done.
remote: Total 2083 (delta 953), reused 1492 (delta 633)
Receiving objects: 100% (2083/2083), 2.08 MiB | 284 KiB/s, done.
Resolving deltas: 100% (953/953), done.
* Successfully added overlay "xake-toolchain".

Confirm that it is there and that it's up to date:

# layman -l
* xake-toolchain [Git ] (git://github.com/Xake/toolchain-overlay.git
# layman -S
* Running command "cd "/usr/local/portage/layman/xake-toolchain" && /usr/bin/git pull"...
Already up-to-date.
*
* Success:
* ------
*
* Successfully synchronized overlay "xake-toolchain".

Time to change the repository to use testing branch which is required for gcc-4.4. If you want to stay with gcc-4.3 skip this step and proceed to editing /etc/make.conf. For gcc-4.4 run this:

# cd /usr/local/portage/layman/xake-toolchain
# git branch testing origin/testing
Branch testing set up to track remote branch testing from origin.
# git checkout testing && git pull && cd $OLDPWD
Switched to branch 'testing'
Already up-to-date.

Now portage has to know that it needs to look somewhere else for ebuilds. This requires change in /etc/make.conf. We need to comment out previous location (/usr/local/toolchain-overlay) and add the new one. Open /etc/make.conf in your favourite editor:

#PORTDIR_OVERLAY="/usr/local/toolchain-overlay"
source /usr/local/portage/layman/make.conf

That should be it. To confirm that portage works as it should try emerging gcc and glibc. For gcc-4.4 you should see:

# emerge -av glibc gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] sys-devel/gcc-4.4.1-r1 USE="graphite gtk hardened mudflap nls nptl (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -openmp -test -vanilla" 0 kB [1]
[ebuild R ] sys-libs/glibc-2.10.1 USE="gd hardened nls profile -debug -glibc-omitfp (-multilib) (-selinux) -vanilla" 0 kB [1]

Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage/layman/xake-toolchain

Would you like to merge these packages? [Yes/No] n

Quitting.

All set! You can safely delete the /usr/local/toolchain-overlay folder. Now whenever you want to update the overlay, simply run:

# layman -S

Saturday, 1 August 2009

John the ripper on mpi steroids or how to crack YOUR passwords faster

Ok, so everybody knows john. John is the ripper. He rips passwords. But he's not always fast enough. However, thanks to this patch he can now take an advantage of your multicore system! Here's the quick & dirty howto.

All required goodies are there in Gentoo portage tree so in a true Gentooer fashion:

# emerge -av openmpi johntheripper

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] sys-cluster/openmpi-1.3.2 USE="cxx ipv6 threads -debug -fortran -heterogeneous -mpi-threads -pbs -romio" 0 kB
[ebuild N ] app-crypt/johntheripper-1.7.3.1 USE="mmx mpi sse2 (-altivec) -custom-cflags -minimal" 0 kB

Total: 2 packages (2 new), Size of downloads: 0 kB

Would you like to merge these packages? [Yes/No]

Make sure that the mpi flag is enabled. After it's done, quick test to confirm it's working:

# mpirun -np 2 uname -rsv
Linux 2.6.29-hardened #13 SMP Fri Jul 24 15:26:08 BST 2009
Linux 2.6.29-hardened #13 SMP Fri Jul 24 15:26:08 BST 2009

Where 2 is number of processors (or cores) available. Ok, ready to go - first benchmarking without multicore:

# john --test
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_pt2pt: file not found (ignored)
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_rdma: file not found (ignored)
Benchmarking: Traditional DES [128/128 BS SSE2]... DONE
Many salts: 1529K c/s real, 1698K c/s virtual
Only one salt: 1253K c/s real, 1392K c/s virtual

Benchmarking: BSDI DES (x725) [128/128 BS SSE2]... DONE
Many salts: 49920 c/s real, 56089 c/s virtual
Only one salt: 48512 c/s real, 53902 c/s virtual

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw: 4933 c/s real, 5542 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 305 c/s real, 342 c/s virtual

There is not much info about the error reported but it does not seem to be critical. Now run with through the mpi:

# mpirun -np 2 john --test
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_pt2pt: file not found (ignored)
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_rdma: file not found (ignored)
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_pt2pt: file not found (ignored)
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_rdma: file not found (ignored)
Benchmarking: Traditional DES [128/128 BS SSE2]... DONE
Many salts: 3178K c/s real, 6754K c/s virtual
Only one salt: 2622K c/s real, 5651K c/s virtual

Benchmarking: BSDI DES (x725) [128/128 BS SSE2]... DONE
Many salts: 102846 c/s real, 222092 c/s virtual
Only one salt: 99703 c/s real, 215022 c/s virtual

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw: 9869 c/s real, 21833 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 616 c/s real, 1353 c/s virtual

Whooaa! That's a bit faster...And here's a more comprehensive guide too. Off course using rainbow tables will be always faster, but: good (big) rainbow tables are needed and if the password is salted than you're out of luck. Anyway - happy cracking! ;]

BTW: Oh and do use loong and complex passwords...also - if you compare full benchmark output, just look how fast is cracking md5 as compared to sha-1 or blowfish...and although john does not support cracking sha512 passwords as of yet, your system probably supports this algorithm for password hashing so...but that's a totally different story!