Making a Cute Robot with Perl
Mark Gardner started the evening describing a project for a GEMS conference. The girls on the team came up with an idea for making a robot-controlled doll. Mark agreed to help with the software and some of the hardware work.
The end result was a robot Pooh Bear, driven by an XBox controller. The left and right joysticks controlled the arms, and the keypad controlled the head. The mechanics involved pieces of plywood and servos. A Pi-top computer (about $200) was the brains of the robot.
A Servo Hat on the Raspberry Pi controlled the servos, using the I2C protocol.
They used the RPi::WiringPi
module to talk to the Raspberry Pi,
and the RPi::WiringPi::SparkFunServoHat
module allowed control of the servos.
The result was a joy_bear.pl
script, which was wrapped in a shell script that restarted the program if it failed.
The project involved quite a bit of trial and error.
The final program used callbacks to control the bear and read input from the controller.
It was driven by a small event loop.
Determining thresholds to keep the sensitivity reasonable was a challenge.
The resulting bear won first prize at the conference.
The girls originally wanted to control a Barbie, but given the size of the hardware, they moved to a baby doll, and eventually the bear. The girls did the presenting and some of the hardware work. Mark did the programming. In the end, the girls were interested in the code and got printouts, so that they could learn from it.
Mark's demonstration of the functioning bear-robot was fun. The group had a few questions, but the results were mostly a hit.
AWStats Flaws
For the next in his series of security presentations, J.D. delved into some of the problems with AWStats. He began with a quick explanation of the AWStats program.
The first thing he decided to try was looking for the pipe symbol in the language file. This might point to potential 2 argument open injections.
Then, J.D. spent some time describing some of the characteristics of the program that made it a good choice to look for exploits. Some things that imply potential problems included:
- The program is one big file
- Lots of global variables
- HTML formatting directly in the code
- Manual processing of the query string
- Subroutines with sigils
- Bad regular expressions sprinkled in the code
- Direct use of
eval
in the code
While none of these are guaranteed to be a problem, they do point to potential issues.
After some examination, he determined that one of the potential parameters is a configuration file.
Since the program reads the configuration file from the server, the exploit would require getting a file onto the server.
Next, he explored the possibility of using /dev/stdin
as the file.
The program does do a file test, which limits some kinds of exploits.
Apparently, the config files support including other config files, and that logic does not include the file test.
A little more exploration showed that he could use /proc/self/environ
as a file to read.
This is particularly interesting since CGI files end up loading information from the caller into the environment.
He pointed out that /dev/stdin
was not actually necessary to any exploit, it was just the vector he began with.
After reporting an exploit generated from the above, he did not report an obvious second version of a path traversal bug in the migrate code.
As usual, J.D.'s explanation was clear and in-depth.
We had 9 people attending this month. As always, we'd like to thank cPanel, Inc. for providing the meeting space and food for the group.