webmin 1.410 insecurities? XSS exploit

I was pondering writing a webmin module for some stuff I am interested in, since webmin looks so slick, and as of version 1.410 has fixed some of its security issues.

So I went to securityfocus.com and tried to see if there is anything that I should be concerned about and found that there is indeed still an XSS vulnerability – http://www.securityfocus.com/archive/1/487656 inherently webmin does not fix all input through a common save method, and so there are spot-fixes here and there, but they missed the module download dialog.

By writing the following into the file dialog textfield (thanks to Aria-Security reporting this in the above page), I was executing javascript in my browser generated from the response of the server:

“><script>alert(‘Discovered By Aria-Security’)</script>

I presume it should be possible to craft a URL link that would execute javascript that silently adds a second root-account and communicates the ip address of the cracked server to a public place…

Generally I found the code of webmin modules to be rather convoluted and will probably not put more time into it for now…


thunderbird does not want to send attachements out of /tmp ?

Strange surprise today, I tried to send an email with attachements and for some reason it fails, and says I should check my temporary directory settings. Up and down the settings I see no such thing. After a bit of googling and the misleading hint to remove a parentlock file, I am getting the idea – its actually throwing files with that precise filename into /tmp. Now thats stupid, who wrote that ? At the very least do a mktemp directory for the application.

So I had to move the files from /tmp ihnto a subdir /tmp/x and voila it works – but also only because I happen to own read/write those files. Otherwise I would have even had to rename them before sending…

Should file a bugzilla report…

The quest for my next digital camera purchase decision – spoiled by the beauty of my ex: the Canon G3

The beginning – Fuji Finepix 1400

This was my entry ticket to the world of digital photography, I loved it and collected tons of really good shots in all categories except low-light. Fantastic landscapes, portraits, macro flower and insect pictures… When technology moved on and I finally had a budget to spend, I spent a lot of time researching and found that the Canon G3 was going to be the best bang for the buck.

The happy days – Canon G3

I used to have a Canon G3 and loved it – vario-angle LCD would allow me to shoot over the heads of crowds, or close to the turf
without having to lie in the dirt. Crisp and clear pictures to the pixel allowed me to crop subimages of amazing quality. I was in love, but unfortunately lost the camera to some thug smashing my car window in Moraga of all places, and grabbed it out of the car. I wanted to buy the G7 but since Canon ruined the product line by getting rid of the vario-angle LCD and the RAW mode (raw reintroduced on G9 but still fixed LCD), so I figured I might as well go with a power shot sd550.

Some examples why the live-view and vario-angle LCD are important to me:
Take a look at these, I did them with live preview to make sure the focus was on the right thing, but without the variolense:

Squirrel eye to eye

I have lots more at home that are done with the G3 and the varioangle that are not possible without:
1. waves crashing – right at the waterlevel
2. turf of a bicycle trail
3. police action against protesters when the iraq war started, shooting high overhead to see whats going on in spite of a crowd in front of me
4. water coming down a small canal, similar to 1. – basically a photo of what you would normally not get to see and which looks very interesting.
The lame days – Canon PowerShot SD550

Way inferior to what the G3, the only advantage was not bulging out my pants pockets the way I did with the g3… the image quality was just not allowing much cropping/postprocessing – lots of megapixels, but once you look at the pixel level it was blurry and grainy.

Now that the LCD cracked, I am ready to buy something that gets me back to where I was with the G3…

Whats next? Nikon D40…

I have a hard time deciding what to do next though, go DSLR with the Nikon D40 seemed like the next logical step price/performance wise within my budget, but like traditional SLR it does not have liveview / vario angle LCD and all the high end cameras that have it are way over my budget…

The PowerShot S5 IS seems to be close to what the G3 was, but as far as I can tell from the reviews, I can expect the picture quality and battery live to be disappointing in comparison.

The upcoming rebel Xsi has the live view feature, but still a fixed LCD…

So far I lean towards either borrowing a PowerShot S5 IS or G9 somewhere and test if it is good enough for me, or do the same with the D40 and see if I can live with having to press my eye against the camera each time I want to snap a picture… any volunteers in the SF bay area?

Update: I got the Nikon D40 and so far I am in love, will post more later… See some examples on my Flickr photo blog http://www.flickr.com/photos/mrmichaelwill/


linux ramdisks – howto pick the right kernel parameters to create 800MB large ramdisks…

To play with the application ansys / fluent doing an out-core solving process that requires fast scratch space, I was attempting to combine several cluster nodes ram-disks through lustre.

The surprise here is two-fold: With kernel 2.6 the old ramdisk-parameter is obsoleted by the newer ramdisk_size and ramdisk_blocksize. The other one is that by default, it fails in a bizarre way:

mkfs seems happy, but mount says “mount: wrong fs type, bad option, bad superblock on /dev/ramdisk, or too many mounted file systems”. A peek in the output of dmesg told me:

EXT2-fs: Magic mismatch, very weird !

Very wierd indeed. I was puzzled, but thanks to http://jackalltrade.blogspot.com/2006/10/step-by-step-set-up-large-ramdisk-on.html I got to the bottom without having to read the kernel source: He ran into the same issue and figured out that it was the blocksize and solved it by specify the blocksize of the filesystem to be 1k instead of the default 4k.

I now use the kernel parameters ‘ramdisk_size=819200 ramdisk_blocksize=4096’ instead since all data I want to store will be in very few large files anyways and so the 4k blocksize is more efficient and more friendly to the lustre tools anyways…

Note that the ramdisk_size is in KB whereas the blocksize is in bytes.