# 28C3 Scariest Talk of the Day

Wednesday, December 28, 2011

We attended Effective Denial of Service attacks against web application platforms by Alexander “alech” Klink and Julian | zeri where they described a really, really easy to implement denial of service attack that exploits an artifact of hash checking which is computationally intensive when the hash table is filled with hash collisions. It is fairly easy to find 2-4 character hash collisions for a given hash functions (and there are only a few variations in use) and as hash operations are performed by default on all POST and POST-like functions, which take (by default) from 2-8MB of data, one can easily tie up a computers CPU effectively indefinitely.

The researchers tested the attack on most web languages in use (and all in common use – only Perl is deployed safe (since 2003) and Ruby 1.9 has a patch available. Every other OS is vulnerable. Today. The attack is only a POST option with a table of delimited hash collision values. You could copypasta a working exploit, it is that easy. The vast (vaaast) majority of sites on the web run PHP, and 1 Gbps of attack vector bandwidth could take down 10,000 cores. With ASP.NET, that 1 Gbps can hold down 30,000 cores cRuby 1.8 (not patched, about half of Ruby installs): that 1 Gbps can keep a million cores tied up.

Yow.

Posted at 18:32:59 GMT-0700

Category: Eventstechnologytravel

# PHP Startup: Unable to load memcache.so

Tuesday, September 13, 2011

I noticed the warning
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20090626/memcache.so' - /usr/local/lib/php/20090626/memcache.so: Undefined symbol "php_session_create_id" in Unknown on line 0

in my apache logs.  Googling for it, some sites suggested that old php.in files might  the cause.  But this is a pretty fresh install so I looked a little further and found a nerdstock note describing a similar problem.  I checked my /usr/local/etc/php/extensions.ini and finding that extension=session.so came after extension=memcache.so I moved it to the top of the file and the errors went away.

Posted at 00:29:25 GMT-0700

Category: FreeBSDtechnology

# PHP default Lat Lon

Saturday, August 13, 2011

Odd choice for the default lat/lon in php.ini

Posted at 02:14:29 GMT-0700

Category: FreeBSDtechnology

# Postie Image Resize Seems Broken

Tuesday, June 22, 2010

I updated Postie for the first time in many years, and it seems my fix for ImageMagick is now obsolete, but another fix may be necessary.

It may be that Postie just doesn’t like the FreeBSD environment. The ImageMagick fix was mostly to point Postie’s hard-coded targets to BSD standard locations. This time through I haven’t found the right code yet as postie-functions.php has been completely rewritten.

Posted at 00:37:32 GMT-0700

Category: FreeBSDtechnology

# A week of tweets: 2010-06-06

Sunday, June 6, 2010
Posted at 02:11:00 GMT-0700

# Table Edit in Mediawiki

Sunday, October 18, 2009

I just installed Ecoli Hub’s TableEdit into MediaWiki.

It went moderately smoothly, except the update_schema.php script failed to prefix the tables, which meant that MediaWiki couldn’t find them.  It took me a little poking around to figure out what was happening, but I got an error that brtext_TableEdit_box couldn’t be found.  Now an unfortunate prefix choice in that it looked to me a bit like br text…  as opposed to brtExt, but once I figured that out I was on the way to a little editing with phpMyAdmin and everything worked.

TableEdit is a step in the right direction for interactive table editing, what I’d consider the biggest weakness of wiki’s at this point.  It seems most of the information I’d put in a wiki would be more efficiently formatted as tables, and as a result I have lots of non-interactive spreadsheets; something that gets confusing on frequently updated, collaboratively edited text.    WebDAV might be a solution for that, and maybe OpenOffice will get “open via sFTP” as an option soon, but until then EcoliHub’s solution is a step forward, though what I still really want is a viably speedy version of Dan Bricklin’s  wikicalc.

Posted at 18:47:33 GMT-0700

Category: FreeBSDtechnology

# Fixing ImageMagick resize in Postie

Thursday, August 7, 2008

I noticed that postie was doing a terrible job at resizing images.

It turns out that the default GD library isn’t super good at resizing – it does a simple subsample and the result is quite jaggy (see the GD version of this image in this post)

I think the version above looks a lot better. It should have been as easy as just turning on the “use ImageMagick” function in the postie config, but it wasn’t that simple. Two files were not where they were expected to be. The easy one is “convert” which postie expects to find at /usr/bin/convert, but under BSD is actually at /usr/local/bin/convert. This isn’t a big deal as there’s a config option to point postie in the right direction. A bit harder is ImageMagick identify which postie expects to find at /usr/bin/identify, but for which there is no config entry.

The fix for BSD is to edit around line 1768 of postie-functions.php and change /usr/bin/identify to /usr/local/bin/identify before the first run or by resetting postie to defaults. If you’ve already installed postie and don’t want to reset the defaults you may need to edit the postie config database (I did) using, for example, PHPMyAdmin and set the value of IMAGEMAGICK_IDENTIFY to /usr/local/bin/identify.

And thus one gets nice, pretty postie thumbnails.

Posted at 02:16:44 GMT-0700

Category: FreeBSDphototechnology

# PHP, Pear, pspell and a core dump

Sunday, April 6, 2008

I’ve been getting core dumps from HTTPD since doing an update which included PHP. This happened to me before and I thought I’d try the same solution again, but it didn’t work. Pear was due an update portupgrade -ra would get to the update and error out. Attempting manually force it was a dead end:
install ok: channel://pear.php.net/Console_Getopt-1.2.2
install ok: channel://pear.php.net/Structures_Graph-1.0.2
*** Signal 11

Couldn’t find any help on pear.php.net except to say it was a PHP problem. That seemed more likely when I found that
# php -v
yielded
segmentation fault (core dumped)

Many fingers point to ZEND, and a few to recode.so but one pointed to pspell.so

I deleted that line from my .../etc/php/extensions.ini and voila:
 claudel# php -v PHP 5.2.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 5 2008 16:51:20) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies 
I recompiled all the whole PHP dependency tree with -O2 and still it works fine and I could update pear right to 1.7.1

Posted at 01:56:34 GMT-0700

Category: FreeBSDtechnology

# DEMO 08 Palm Desert

Friday, February 1, 2008

Capsule summaries of the companies presenting at DEMO 08 in Palm Desert. 76 reviews continue past the break (click to expand):

Posted at 16:55:51 GMT-0700

Category: reviewstechnology

# fixing GeoIP for awstats

Monday, October 22, 2007

https://web.archive.org/web/20101102191506/http://forum.maxmind.com:80/viewtopic.php?t=27 helped, but the real key was hardcoding the database location in geoip.pm line 63: if (! $datafile) {$datafile=”GeoIP.dat”; } to if (! $datafile) {$datafile=”/path/to/GeoIP.dat”; } .

Posted at 10:45:14 GMT-0700

Category: FreeBSDtechnology