Engels started playing with Linux® in 1991 and obtained his Red Hat Certified Engineer (RHCE), Red Hat Certified Instructor (RHCI), and Red Hat Certified Examiner (RHCX) certifications in 2002. He is in charge of Bluepoint's Total Linux®, Linux Kernel Internals®, Perl & Python Programming, and Extreme PHP curriculum and instruction development.
/* Conveniently yanked from the Bluepoint Institute profile page */
Richard Keech, RHCE, RHCX conducted my RHCE, RHCI, and RHCX training & certification in his capacity as Red Hat Asia-Pacific's Chief Instructor. Before we parted ways, he congratulated me for becoming the first Filipino RHCX. I told him that I was trained by the best.
In loving memory of CPT Mario B. Mortega Sr., USAFFE, VET (1920-2004)
A Note on Security in PHP
Wednesday, Jan 12, 2005, 3:35 PMThe PHP Development Team has issued an important statement that deals with the security of PHP, and of PHP-based applications. The trigger for releasing this statement was the growing misconception in the PHP community regarding recent security problems, which exploited bugs in PHP applications, rather than bugs in PHP itself. It's a recommended read for anybody using PHP.
A Note on Security in PHP
PHP is a powerful and flexible tool. This power and flexibility comes from PHP being a very thin framework sitting on top of dozens of distinct 3rd-party libraries. Each of these libraries have their own unique input data characteristics. Data that may be safe to pass to one library may not be safe to pass to another.
A recent Web Worm known as NeverEverSanity exposed a mistake in the input validation in the popular phpBB message board application. Their highlighting code didn't account for double-urlencoded input correctly. Without proper input validation of untrusted user data combined with any of the PHP calls that can execute code or write to the filesystem you create a potential security problem. Despite some confusion regarding the timing of some unrelated PHP security fixes and the NeverEverSanity worm, the worm didn't actually have anything to do with a security problem in PHP.
For Local exploits we mostly hear about open_basedir or safemode problems on shared virtual hosts. These two features are there as a convenience to system administrators and should in no way be thought of as a complete security framework. With all the 3rd-party libraries you can hook into PHP and all the creative ways you can trick these libraries into accessing files, it is impossible to guarantee security with these directives. The Oracle and Curl extensions both have ways to go through the library and read a local file, for example. Short of modifying these 3rd-party libraries, which would be difficult for the closed-source Oracle library, there really isn't much PHP can do about this.
When you have PHP by itself with only a small set of extensions safemode and open_basedir are generally enough to frustrate the average bad guy, but for critical security situations you should be using OS-level security by running multiple web servers each as their own user id and ideally in separate jailed/chroot'ed filesystems. Better yet, use completely separate physical servers. If you share a server with someone you don't trust you need to realize that you will never achieve airtight security.
Open Source Bill
Brakes Part II
SSL Version Control
Software Freedom Day 2006
More Than Geeks™
Corazon Aquino (1933-2009)
MAJ - My Activity Journal
Writing Custom udev Rules
Pacita Laurinaria (1939-2009)
Nmap 10th Anniversary
So There You Are!
Brakes Part I
Francis Magalona (1964-2009)
Recalled to Active Duty