YOU'RE DOING IT WRONG! Part 3a: Intersections

I haven't written a YOU'RE DOING IT WRONG in quite some time now, and most of this whole time I've been getting pissed at more bad driving habits...and some of the same old ones.

One topic that I've been thinking about quite a bit is intersections. As a driver and as a pedestrian. They're just another thing that it seems like the driving community can't figure out.

So part 1 of intersections is the pedestrian perspective.

I tend to cross the road 2 or 3 times a day, due to the retarded parking situation at RIT, and I HATE doing this when there are cars on the road. Not that I worry about getting hit or anything like that, I HATE the way other drivers react to pedestrian intersections.
We're all taught pedestrians have the right of way. Unfortunately this combines with the modern driving tendency of relentlessly giving up the right of way when they shouldn't be (in the name of COURTESY) and you have people in command of ~5,000 lbs vehicles wearing their break pads and wasting energy (read: GAS) to stop their cars in intersections they could have CROSSED before a pedestrian got to it.

So this whole wasteful habit comes from an overdone forced politeness that society is too fond of today. But it's actually very rude.
Because you stopped your car before I even got NEAR the intersection, because you were so scared of my pedestrian ass feeling offended at you blasting your car past me now I need to hurry up and jog past you so I don't make YOU wait.

You would get pissed off at a driver who stopped at a green light because there was another car 40 feet up the road.

I'm pissed at you stopping at a crosswalk when I'm still 10 feet from the road. Seriously. If you can make it through before I get there...or HEY if your passing would make me wait a whole 3 seconds...do it. It's easier for me to stop 260 lbs than it is for you to stop 6,400 lbs.

Learn to judge distance, if I'm 10 feet away I'm NOT in trouble. LOOK OUT for pedestrians, but stop this overly polite bullshit and drive your damn car.


This installment of YOU'RE DOING IT WRONG is brought to you by Sudafed.

--PXA

More Cisco Linux VPN problems

I have noticed another issue with Cisco's VPN for linux, this time in the form of a module that inserts fine but won't connect. /etc/init.d/vpnclient_init status reports a good module but the interface can't be found.
When I saw this my first inkling was to see if I could change the name of the interface it's looking for in the initscript, this made status report good but the client still won't connect to anything.
This is because Cisco, in their infinite "wisdom" decided to hard code the name of the interface into the driver itself.

Your best bet is to figure out what udev rule is forcing the rename...it's probably in the file /etc/udev/rules.d/70-persistent-net.rules

Only other option is to rewrite parts of vpn_ioctl_linux.h to change the device name the driver tries to use to the one it's getting anyway, or change the MAC address and hope /etc/udev/rules.d/75-persistent-net-generator doesn't mess with your device when you reload the module.

Matter of fact, it'd be a cool patch to change those on the fly.

Hmm,

--PXA

Mini-update: KDE4

I just rebuilt KDE 4.1++ from SVN sources, and frankly, it makes me want to kill small puppies.
This is the list I have compiled after approximately 15 minutes of use.

1. I tried to use the auto-hide, KDE4 does not like this. To trigger the taskbar's visibility you need to get all the way to the screen side where the panel lives, then back off several pixels. And hope. The panel would sometimes not respond or become visible then immediately fade. But the edge of the screen itself does not respond to input at all.
   
2. For me, KDE starts without window decorators, if I try to enable them the panel gains a title bar which doesn't seem to accept input. This causes some problems when trying to open the panel settings. The panel settings are cool when they open since they attach to the panel. But when this titlebar is open you need to quickly cross it to get to the configuration panel, a lot of the time you will lose both panels.
3. Desktop Folder is the crappiest thing I've seen in a long time, I would LOVE to turn this off and get a real desktop. I can't.
4. The focus is very strange, to bring a window to front you need to click on its TITLEBAR, not anywhere in the window... I'm hoping that's a settable option but I couldn't battle the interface enough to get to the control panel so no idea here. If this is default, it's just a stupid idea.

Maybe I'll try more later, maybe I'll delete it again and wait for KDE 4.2. Anyone have any GOOD things to say about KDE4?

--PXA

Cisco Linux VPN on kernels 2.6.19+ (And x86_64)

Cisco seems to have been screwing the pooch recently when it comes to releasing good installers for their VPN software. A version of the VPN client for windows released last February had a nasty glitch where it tried to iterate every group in RIT's active directory environment 4 times. And the previous version of the Linux VPN (4.8.00) unceremoniously broke with kernels higher than 2.6.19 and remained officially unpatched (There were only community written patches) for several years. Cisco recently released 4.8.02, which brings with it full compatibility with modern kernels (tested up to 2.6.25)

However, to compile on a 64 bit kernel the module included code which modifies the compiler flags (or CFLAGS) to build correctly on 64 bit kernels. The linux build system for kernel modules (called Kbuild) does not allow makefiles for modules to modify CFLAGS directly, so it accepts a parameter called EXTRA_CFLAGS. The Makefile for Cisco VPN Client for some reason uses EXTRA_CFLAGS fine normally but in the conditional for 64 bits uses CFLAGS directly, causing the build system to throw a hissy fit. So the simple fix is to change line 15 of the Makefile for Cisco VPN 4.8.02 from

CFLAGS += -mcmodel=kernel -mno-red-zone

To

EXTRA_CFLAGS += -mcmodel=kernel -mno-red-zone

Then there's a whole slew of other issues with 64 bit kernels which are fixed by this patch.
(patch linked from http://www.lamnk.com/blog/, and written by Steven Frost)

At least there's a positive note with that: A codebase patched for 64 bit will still compile (albeit with warnings) on 32 bit systems.

I see stuff like these issues, and I've gotta wonder...Do they TEST this stuff? At all?

--PXA

How To: Break MOLLY!

I have wanted to post this for a long time now, but I had previously been afraid of retaliation by RIT's IT department since this exploit was discovered using their public facing website. However, http://it.rit.edu and http://nssa.rit.edu have both recently switched from Molly, a pseudo in-house solution written mostly by Ronald Vullo. Molly's status as a publicly available CMS from sourceforge opens the possibility that other people outside of RIT will be using it, and these people would probably appreciate being told about a security vulnerability in their software...unlike the IT department which would likely try to expel me or prevent me from graduating on schedule. (Yeah, I have great faith in these people.)

Anyway. Molly stands as a key case example for how you should NOT write PHP. It makes heavy use of BAD-THINGS ®, does not use any sort of legitimate string munging to prevent SQL injection, and has almost no concept of session security.
As for bad things, I mean things like polluting the global namespace, using .html files with PHP in them, the eval() statement, old functions like eregi_*(), and heavy use of $_REQUEST as opposed to $_GET and $_POST. The PHP manual itself states that $_REQUEST cannot be trusted, as you do not know which of Environment, Cookies, Get, Post, Server sources provided the variable you're looking at in $_REQUEST or if one has over-written what you actually want.

The most glaring exploit I've found, however, is related to the rendering engine the the database module (Called forms). Molly controlled pages will often have some string in their URL which tells the Molly engine how to render said page, example: people.maml?id=77&renderAs=output Or renderAs=edit
Yup. I can just see all the tech minded people thinking "What if I change output to input?".
When RIT used Molly, exactly what your worst fears were, is what happened. Each element on the page became HTML Input.


After that point it became trivial to use the Firebug plugin for Firefox to modify the contents of the page on the fly to make Molly bend over for you. To update any record you wanted, it was a simple matter of navigating to that page, changing the URL, using firebug to change the form action from "insert.html" to "replace.html" and adding a value to a hidden input element named something along the lines of "form[0][id]".

Since Molly doesn't understand security, the files which parse the form input and create the SQL queries are wide open for all to access, as long as you can post the right information.

One way these can be protected is through the use of an .htaccess file using the directive and some form of HTTP authentication. And that's probably the simplest way, but I don't know if there's anything resembling security on the rest of the engine that could be expanded to these files.

YOUR CODE IS BAD AND YOU SHOULD FEEL BAD TOO!

--PXA