Mine the Harvest

NOTE: Since the original post I discovered a new version of PHPChain is available at the project Sourceforge site here. You may test drive it here. The new version has several additional features and the issues with the underlying PHP code described below have been corrected. I had no issues running the new version with PHP 5.3. Unfortunately, there is no way to easily migrate your database from the old version, but the new version does allow the import and export of data in XML format.

PHPChain is a great little app which helps you organize passwords. It uses a web interface, encrypts the passwords in a MySQL database, and supports multiple users, each with their own account. Passwords are organized in user defined groups, and are easy to edit. It automatically alphabetizes entries, helping to organize them further. The interface is extremely easy to use, and it makes storing and organizing you many passwords very easy. You can try a demo of it here.

I opted for this as a solution to store my passwords at home. It provided the added benefit of having access to my passwords from anywhere over an SSL web site. While there may be some slight risk in this, lets be honest — it is a hell of a lot better than the open office document I was using before. And of course you can further protect it by only opening the port it listens on when needed, and even place it behind an .htaccess, etc. You can be as paranoid as you like.

The one thing is that this application does not appear to have been  updated in a while, and if you install it today you may run into a situation where PHP does not read some of the scripts as the author used php short tags

Here are some notes that might help you with your install.

First of course you will need to install apache with the necessary php and ssl packages, as well as php5-mcrypt installed. You will also need to generate a self signed SSL certificate and set up a vhost that will accept SSL connection. You certainly want to use SSL, even if you intend to only access this on you local network as otherwise all traffic will be sent clear text, which would be bad. Setting up apache to use a self signed SSL is pretty straight forward and there are lots of sites for your distro to guide you in this.

At a minimum you will need things like:

apache2-2.2.13-2.3.1.i586
apache2-mod_php5-5.3.0-2.4.3.i586
openssl-0.9.8k-3.4.i586
apache2-mod_php5-5.3.0-2.4.3.i586
php5-mcrypt installed
php5-mysql-5.3.0-2.4.3.i586

Once you download PHPChain, simply extract it in your web document root and create and empty MySQL database, them import the .sql file into it. See the README.txt for details. If you access it now, you will likely see lots of messages as some scripts are not being parsed correctly due to the short tags being used. Find which ones this are by:

Callandor:/srv/www/htdocs/phpchain # grep -R ” ./cat.php: ./inc/menu.php: ./inc/db.php: ./inc/cookie.php: ./inc/header.php: ./inc/header.php:PHPChain – Powered by PHPChain
./inc/header.php: ./inc/header.php: ./inc/header.php: ./inc/header.php: ./inc/crypt.php: ./inc/form.php: ./index.php: ./login.php: ./logout.php: ./newlogin.php: ./password.php: ./settings.php:

Change all instances of the

Callandor:/srv/www/htdocs/phpchain # sed “s/> testchange; sed “s/> testchange

To virst view the changes in each file, and then if it looks good replace with:

Callandor:/srv/www/htdocs/phpchain # sed -i “s/

Or, to be even fancier with it . . .

Callandor:/srv/www/htdocs/phpchain # for i in `grep -R “

Now, the php should work correctly, but you will likely have some warnings dispalyed at the top of the page regarding some constant variable declarations. You can disable php warning by setting the error_reporting level on a per script basis. Turn off errors and warnings in index.php (before the include statements) by adding:
error_reporting(0);

Or set the error reporting level in you php.ini

That should do it, you an now start using PHPChain to manage your passwords in a more secure way. Do ensure to use SSL, and if you connect without SSL PHPChain conspicuously warns you of the danger of this.

Standard Disclaimer: This article makes recommendations on using tools to modify your LVM configuration, your /boot partition, kernel and grub. Data corruption from a mangled LVM, or a (temporarily) unbootable system through a corrupted or mis-configured grub, etc. are entirely possible. I am not responsible for any of this. If you have a running system and break it by changing these things, please realize that I am not to blame, nor will I be able to help you fix things. And of course, making complicated changes on a production environment is not advised. However, if you need to migrate to a larger /boot partition the following may help you. If you are unfamiliar with partitioning, LVM and grub, please plan on having a least a few hours to work your way through this the first time. Also, have a Live CD and possibly the SuperGrub CD already available before hand. You may also want to practice on a virtual machine before trying this on a running server, etc. Installing Virtualbox and setting an a test VM takes only minutes and provides a superlative learning environment.

There is only so far you can get with a 69M /boot.

If you are like me, when you last installed your distro you likely decided to go with the proposed LVM layout. Hey, why not right? This way you can more easily change the sizes of your logical volumes, adding more to home, stealing some from that /whatever slice you just never really ended up using. Plus you can always add another physical drive later for juicy (or potentially disastrous, I’ve heard it both ways) multi-volume LVM expansion goodness.

Or perhaps you just said “yea, sure — whatever” on the partitioning steps.

Despite the best, or worst, planning you at times just need to fix what you are left with.

In my case, for some reason know to only God and the face on Mars, when I last installed Suse I accepted the offered LVM layout, and along with the the pathetic 69M /boot partition. Well, as you start to add some other kernels for Xen, the Suse default and desktop kernels, and if you want to keep any old versions of these, or compile your own, you very quickly realize what a mistake you made.

Now, fixing this is not superlatively difficult of course, but there are easy ways and hard ways.

The hard way involves manually shrinking the LVM Volume Group (vg) which also requires shrinking the Logical Volums (lv) which it contains, which of course requires shrinking the filesystems they contain. Oh the pain.

(continue reading…)

Cool News: This post was a blogging contest winner!

Thank you Sun!

Update: What a pleasant surprise to find that my entry for the Sun Studio blogging contest was selected as one of the winners, and announced on the Sun Studio Developers Site. As promised, Sun sent along $500, marking the first money I’ve made with this blog, and while my purpose in blogging is not focused on making money, it nonetheless was a nice side effect. I certainly enjoyed writing about my initial experience with using Sun Studio 12, and to have been selected as one of the contest winners was certainly a bonus. Thank you Sun Microsystems for holding the contest, and of course for making Sun Studio available to the community.

Every now and again I get emails from Sun Microsystems for guides or other promotions for this or that product: ZFS, Solaris containers, DTrace, etc. Some of them are actually quite interesting and it is a list I like being on.

The other day I received an announcement for the release of Sun Studio 12 Update 1. Well, this was perfect as I have been wanting to test drive Sun Studio for a while, and have been meaning to get to it – but it gets even better: they are having a blogging contest and will actually be paying 10 lucky winners who blog about their experience with it!

Well, let’s see: try out and write about a product which I had intended to do anyway, and perhaps win some cash too – how can one possibly go wrong?

Why Try It?

I’m neither a developer nor programmer. If that fits you as well, you might be thinking “So why bother?” Well, like a lot of folks out there who are Linux guys, sysadmin types, etc. I think it is always good to be familiar with available tools. The IDE I’ve used most is vim, and I’ve rarely even used Eclipse. But I, being an adventure loving soul, of course love checking out new things and was particularly interested in the Sun compiler as I wanted to compare its optimizations and the performance of binaries it compiles against the Intel (icc) and GNU (gcc) compilers. I previously wrote on comparing Intel Linux C complier and gcc binaries using the Crafty chess engine and was quite surprised at the benchmark differences, and have since then wanted to see how a Sun compiled binary would compare. So what a perfect opportunity to try it and find out.

Isn’t that a bit nebulous? One could even dare say Geeky?

While benching chess engine binaries might seem somewhat esoteric, it really gives a good idea of the possibilities. Translate this over to compiling your MySQL server or other performance critical app and it starts to get more interesting. In fact you can get MySQL binaries compiled with the Intel compiler for just this reason directly on the MySQL download page. One can’t help but wonder one MySQL binaries compiled with the Sun compiler might perform.

Install Experience

I tested out Sun Studio 12 on both Solaris 10 (2009.06 Nevada) and Linux (Suse 11.1) platforms. In both cases the install was seamless. On Solaris 10 it was simply a matter of using the new IPS packaging system and  by running

$ pfexec pkg install sunstudio12u1

it was up and running in minutes.

On the Linux side I downloaded the SunStudio12u1-Linux-x86-rpms.tar.gz package and simply run the install wrapper script, which by default places everything in /opt/sun and the full path to the binary is then /opt/sun/sunstudio12.1/bin/sunstudio (you will need to add that to you PATH environmental.)

The GUI installer which ran in Linux went smoothly and gave basic options for which components to select, etc. You can also install install in non-interactively. The displayed warning was simply saying there was no guarantee it would work on this system (Suse 11.1) – but there were in fact no issues.

Sun Studio Installer on Suse

The full install (C and Fortran compilers, performance libs and IDE) comes to about 755MB on Linux and about 830Mb on Solaris – a bit larger than I expected.

Sun Studio IDE

Sun Studio 12 On Suse 11.1

Launching Sun Studio presents a clean and easy to navigate environment. Though never having used it before, it was pretty obvious where to find things. Several sample projects are available so you can test drive it right away, and there are links to guides presented on the main page. (There is also a comprehensive quick start guide here.)

I did have to play about a bit with adding existing directories of source code into a new project. It is easy enough once you do it. Once you import your source, you can click the build button and you are more or less off.

Of course, you will need to define the full path to the compiler you want to use in the CC= variable in the make file, or have this environmental defined and exported already. If you want to compile with gcc instead, it is no problem – just set cc=gcc  In the Crafty make file you can simply set the $(MAKE) linux or $(MAKE) linux-icc to use gcc or icc compilers. I had no difficulty compiling Crafty with gcc this way.

Using the Sun Compiler

As I am utterly unfamiliar with CFlags for the Sun compiler I found it nice that just running the compiler with no arguments immediately tells you how to discover them easily enough with /opt/sun/sunstudio12.1/bin/suncc -flags

I had to figure out the CFLAGS still though, and found this site to be helpful for that.

One I had the correct options set in the Crafty Makefile, the Sun compiler launched into action for me. I used a basic set of CFLAGS:

solaris:
$(MAKE) target=SUN \
CC=/opt/sun/sunstudio12.1/bin/cc CXX='$(CC)' \
CFLAGS='$(CFLAGS) -fast -xO5 -xunroll=20' \
CXFLAGS=$(CFLAGS) \
LDFLAGS='$(LDFLAGS) -lpthread' \
opt='$(opt)' \
crafty-make

Compile Benchmark Results

So how did it go? How did the Sun compiler perform? Well come back in a day or so and see the benchmarks. Meanwhile, you might enjoy reading about how the previous comparison between Intel icc and gcc tests went, which you can find here.

It seems we are  always reading  update notes saying:

“Fixed a potential buffer overrun condition which if exploited could result in the attacker executing arbitrary code and possibly escalating privileges.”

These exploits are extremely common, and of course patches and updates to correct such are equally common, regardless of the OS platform.

I of course had a generalized understanding of how these exploits worked – but I’ve recently decided to really dive in and greatly increase my knowledge in this area. A superficial understanding was no longer sufficient and I wanted to not only understand better, I wanted to learn how to leverage such exploits with hands on hacks.

So – I armed myself with some material, starting with “Hacking:  The Art of Exploitation” by Jon Erickson loaned by a colleague. As it turned out the first edition of this book was published in 2003. Since then there have been many changes in both gcc and recent versions of the 2.6 kernel that greatly improve stack security. Thus the sample code in the book is no longer capable of simply being compiled and executed to achieve the desired result.

I ended up learning just as much getting the first exploits to work correctly in more modern distros as from the text itself. But its all part of the educational process and I certainly understand the current kernel and gcc operations a bit better. And I was able to make the first lessons work.

Making Old Hacks Work

The best way I found to get the code to compile and run as intended was to use an older OS and Kernel in Virtual Box. I installed a basic install of Ubuntu 6.06 and used that. The 6.2.15 kernel it had allowed the exploits to run, if you tweaked it.

By disabling randomize_va_space in /proc/sys/kernel and by compiling with an earlier version of gcc (3.3 and 4.0) the results were achieved:

The exploit is a simple one, but a classic. It simply rewrites the return address by over flowing the buffer, taking control of the execution flow of the program that calls it and directing it to run a snip of shellcode. The shellcode is a self contained piece of assembly that spawns a shell. Because the program that is called is an suid root program, and runs as root, a root shell is opened.  (Note there are several suid binaries installed on most systems and a similar exploit against any of them could potentially achieve the same.)

The source for the two programs for this exploit can be found here and here.
(Ensure vuln is owned by root and has the suid bit set with chmod +s)

To Learn More

I recommend the new second edition of Hacking The Art of Exploitation by No Starch Press, which you can review here.  The new version looks like it takes more modern compiler and kernel design into account and has expanded content as well.

Current GCC and Kernel Operation

Note that more recent versions of gcc (4.2 and higher I believe) compile with stack protection enabled by default. To compile without use:

user@system:~/$ gcc-4.3  -fno-stack-protector -o exploit exploit.c

Also, you may find reading up on stack protection and the following kernel options to be helpful:

root@paracelsus-laptop:~/hacking# cat /proc/sys/vm/mmap_min_addr
0
root@paracelsus-laptop:~/hacking# cat /proc/sys/vm/vdso_enabled
0
root@paracelsus-laptop:~/hacking# cat /proc/sys/kernel/randomize_va_space
0

A while back when Linux Mint 6 XFCE (based on Ubunut Intrepid) was released and reviewed on The Linux Action Show I thought of what a good platform it could be for the OLPC. (The Linux Action show is a great pod cast by the way!) I had previously installed Ubuntu Hardy on the OLPC, but the extras the Linux Mint guys added to XFCE sounded pretty cool. Especially considering I am thinking of giving the OLPC away to someone who is a newer Linux user, having Mint as the OS was pretty appealing. And oh, my old Hardy install was utterly nuked on the SD card anyway – who knows. I might have tried to recover the partition tables with TestDisk, etc. but really – who cares. Time for a new OLPC adventure anyway!

In fact I had hardly touched my OLPC in nearly a year, since buying my Acer Aspire One – which I really love. And although the Aspire One is obviously far better performance wise, there are certain characteristics of the OLPC that I really like, such as:

Monochrome Screen Mode: This is absolutely awesome. The screen back light turns completely off saving big time power. Sunlight goes through the LCD and is reflected off a panel, making the screen extremely readable in direct sunlight. It is really fantastic and I wish ALL netbooks had this feature. It is hard to describe how legible it is, even in harsh direct light.

Battery Life: Especially when running in monochrome mode, battery life is quite good.

Mesh Networking: Interesting stuff – and oh, the wireless net supports injection. Hacking opportunities for kids the world round.

Case Design: Everything folds up to protect ports. Integrated carrying handle.

Open Firmware: Yea, it’s kind of different and fun to play with. Similar to the Open Firmware in the pre-Intel Macs, but far more fun than that was. Since we will be seeing a lot more systems using Open Firmware in the future it is good to play with it now. By by BIOS – you served us well.

Philosophy: Providing technology that would otherwise be unavailable to kids in remote places does not at all seem like a bad idea to me.

HAM Radio: I am thinking the OLPC, with the above features, seems a perfect candidate to use with packet radio. Communicate with friends after the coming apocalypse. Run it for years, and never worry about the back light burning out – you don’t need it.

(As a note: It was great seeing a few people recently at Toorcamp with their OLPCs – I saw two or three there, as well as two OLPC billboards on the trip to Seattle.)

Okay – enough extolling the OLPC virtues. How to install Linux Mint on it.

How to Install Linux Mint 6 XFCE on the OLPC

0) Pre-install Steps

0) First off, you do not need to go through exotic hoops to get this to work. Some guys have had success installing Mint onto an SD card first and then installing Hardy over the top of it and ended up with a working Mint install. Using the following method you can simply install Mint and it should work fine. (If you do want to install a vanilla Hardy, I would highly recommend using this method using compressed files instead.)

00) I suggest you update the OLPC firmware and Fedora base OS before installing Mint. Simply connecting to a wireless network and running #olpc-update as root will download all updates and update the firmware as well. (Have it pluged into AC or the firmware upgrade will be skipped.) BE PATIENT – the upgrade rsyncs several hundred megs over your wireless connection. It takes a very long time.

(continue reading…)