Bash Shellshock Vulnerability - What's the threat?

Below is a link on github wherein the Bash Shellshock vulnerability is being discussed:

https://gist.github.com/anonymous/929d622f3b36b00c0be1

For the non-technical, what is being shown by posters is that the now termed Shellshock vulnerability is now being used.  Attempts to use the vulnerability are being captured in log files - particularly note the UserAgent notes in the log files as they illustrate the attempt to use the vulnerability.

What is particularly alarming is just how easily this vulnerability can be used and also what appears to be an attempt in the log files to search for vulnerable machines.  The "grep" command on Linux is an advanced and complex search command that can be used to execute very specific searches.  Note the comments in the link where grep is mentioned.  A list of websites with the vulnerability would be valuable indeed.  However, so would a list that contains any type of machine with the vulnerability. 

This vulnerability affects much more than just websites - MythTV boxes and other entertainment boxes running Linux (Boxee?  TiVo?) could also be affected.  It could even affect security cameras or for that matter any device that has an available Bash shell.

This is a particularly scary vulnerability because of its ease of use and power.  Using the Shellshock vulnerability, it is possible to obtain files that were supposed to be limited to root access.  In other words "Got Root?" isn't a question - it's  an assumption.

Oh and by the way, Mac OSX systems are also affected since they also have Bash available.

Imagine a SCADA running Unix at a steel mill and it is connected to the Internet for customer convenience.  Naturally, there is security in place to prevent anyone except customers from accessing the SCADA webpage data.  However, with the latest Bash vulnerability anyone that can type a simple script can access that SCADA.  Who cares you may ask?  Its just production data.  Why would anyone want it?

The problem, in this case isn't that data may be copied, as in credit card numbers theft.  The problem is what could be done if someone on an outside connection can control that machine?

Of course the attacker would need to be running the actual SCADA software to interact with equipment, or would he?  Could he just directly access the database that the SCADA uses to keep track of and issue equipment commands?  Could he access the database and change the product recipe? 

But who cares about a steel mill right?  Well the issue is that Unix and Linux based SCADA are used in a wide range of industries from power generation, oil production, transportation, semiconductor fabs, and  utilities.  All it takes is one machine connected to another machine connected to the Internet and the scenario depicted above can become very real. 

There's no need to panic - yet unless you happen to be in IT and manage systems that run Unix, Linux, or Mac OSX.  On the other hand,  security research Bruce Schneier is calling the flaw "catastrophic."

If important systems, besides just commerce and finance, do not get patched before a Shellshock worm is released, we could have serious problems that would make the finger vulnerability, the Morris worm, Heartbleed, and the Code Red virus, seem almost innocuous in comparison.

2007 Nissan Sentra accelerates by itself!

On August 22, 2012 I posted about our 2007 Nissan Sentra attempting to accelerate out of control in reverse. We had it checked by Nissan mechanics and they found nothing wrong or in their log. Yep your modern car has a log file in it.

I was even shown that slamming the brakes automatically overrides the accelerator even if your foot is on it. That's a good safety and so I figured if the problem ever resurfaced, we would still be safe - just slam the brakes.

Yesterday, 9/11/14, our 2007 Nissan Sentra accelerated all by itself! It went into runaway mode again but this time in drive!

We were in a McDonalds drive through and had just placed our order. The car was in park. The AC was on but not on Max AC. I put my foot on the brake and shifted to Drive. The car lurched forward but the brake held it. My wife Kelly exclaimed, "what are you doing?" 

This time I was ready except I had no camera or smartphone. Damn!

I said to Kelly, "Look! There it is! Look at my foot, it's not touching the gas at all - just the brake. Look at the tach. It's racing up to 2500 and coming back down. It's in drive." 

Kelly asked, "What do we do?"

I said, "Watch this!" I slammed the brake to the floor as hard as I could. Everything went back to normal. I said, "see that mechanic was right. Just slam it to the floor (the brake)."

"Are we safe," asked Kelly.

I answered, "I guess so. If anything happens we just slam the brakes. Nissan will never find this. It wouldn't do any good to take it in; they couldn't find it the last time."

"You sure we'll be okay", asked Kelly.

"I don't know but I'm putting it online so that it's at least documented somewhere if anything happens. At least we have a brake override to kill it?"

Kelly asked, "do you think Nissan knew about this?"

I answered, I don't know but at least they planned for it. I wonder if they found it in testing and added the override because they couldn't find the bug causing it?"

-- end of story - 

I think it likely has to do with the air conditioning. The engine has to compensate when the air conditioner kicks on or stall. It is likely that the software has an endless loop that occurs when the AC kicks on under just the right circumstances. Or it could be an integrator problem.  When trying to regulate speed electronically, oftentimes a PID loop is used.

PID stands for Proportional Integral Derivative.  To put it simply, an equation would look at the speed command for the engine, see how far off it is which is basically the proportion, and then use integration to consider prior responses and use derivative to offset the integration and proportion.  That is an extremely simplified explanation of PID.  If you understand mathematics pretty well, look up PID equation on Wolfram Alpha to help understand the relationship between the P the I and the D.

The problem that can occur is called integral windup.  What happens is that each new addition to integral becomes progressively larger until derivative is no longer able to offset the integral.  To put it simply, it's like dividing one by zero.  Of course it is undefined but if you instead divide by a number as close to zero as you can possibly get, such as 10 raised to the minus one million, then the result of the equation is enormous.  Just imagine that number being applied to the accelerator of your car!

I used to always include a safety clamp in software for the PID result just in case of integral windup.  Some people frown on such practice and are of the opinion that if the PID loop is setup properly then there's no need for a clamp.  I strongly suspect that the software used in our 2007 Nissan Sentra and in many other cares is the result of such debates and probably lacks and software clamp for the PID loop.

At least Nissan has an override, although scary. I wonder about the other car companies...

Basic Atom Pro Timer Interrupt

While working on obstacle avoidance code for the autonomous mode, it became desirable to have a way to detect the amount of time that has expired. This is especially useful for detecting how long the robot has been stopped and how long it has been walking in a given direction.

Adding a timer interrupt in Basic Atom Pro code is actually quite easy - there is an example in the Basic Atom Pro manual.

The following two commands configure a timer interrupt on the Basic Atom Pro:
ONINTERRUPT TIMERAINT,handle_timerA
TMA= (TMA & 0xF0) 0x4 ;sets timera to increment once every 256 clock cycles

Here is the code that will run each time the interrupt is triggered:
handle_timerA
currenttimerval = currenttimerval + 1
resume

In the code listed above, TIMERAINT is an overflow interrupt and when this interrupt occurs, handle_timerA routine is executed and returned from by the resume command - the routine just counts 256 clock cycle clumps as one interval called currenttimerval.

Here is the code that starts the timer timing:
ENABLE TIMERAINT

Simple stuff. Stopping the timer is just as easy:
DISABLE TIMERAINT

So, we now have an easy to use timer that we just enable to start it ticking and disable to stop it. By the way, there is no explanation in the Basic Atom Pro manual regarding TMA other than a comment in a code listing. For an explanation on TMA, it is necessary to look in the h83664 manual. At first glance, it was a little challenging to understand but as with many things it was just a matter of staring at it long enough until the picture became clear, so to speak. There is also a comprehensive tutorial on the Lynxmotion forums that helped.

It wasn't until I stumbled upon the interrupts tuturial posted by a user in the Lynxmotion forums at http://www.lynxmotion.net/viewtopic.php?t=3496 that I found a caveat about using interrupts on the Basic Atom Pro. It seems that serout commands on the Basic Atom Pro are not always reliable when using interrupts. I confirmed this to be true after watching the Midnight Prowlerbot spasm and twitch in a random fit instead of walking as programmed. At first, I thought that maybe I had done something wrong in my code. After putting DISABLE TIMERAINT before every serout command and ENABLE TIMERAINT after each serout command, I found that everything worked fine. The robot walked as expected. The timer worked.

Unfortunately, enabling and disabling the timer interrupt before each serout command really affects accuracy of the timing. For instance, if the robot is instructed to perform a command that isn't executed each loop, such as an attack sequence, then the amount of time that the timer has been disabled has been changed when compared to just a walking sequence. Although this is not a crucial problem for things such as telling the robot to stop for a few seconds, it could be a problem if more accurate timing was needed.

Since I found the enable/disable interrupts before and after each serout to be an annoyance, I decided that it would be best to simply not use the interrupt. Instead, the Midnight Prowlerbot now counts the number of steps that it has taken when attempting to avoid an obstacle. For instance, this allows the robot to walk left three steps when any forward obstacle is detected instead of attempting to walk left for two seconds. In the future, more complex avoidance sequences than the left turn algorithm will be attempted.

CMUCam2+ with Basic Atom Pro continued...

After initializing, calibrating, and configuring the CMUCam2+, it is now ready for service to do object tracking, motion sensing, or even histogram capture. The code samples provided use the CMUCam in polled mode so that the CMUCam is not continuously dumping information the Basic Atom Pro. This allows the Basic Atom Pro to request the data when ready, rather than using interrupt code.

Since the CMUCam does not work with the hardware serial port functions (hserin,hserout) on the Basic Atom Pro, it could be a little tricky using an interrupt and using the software serial port functions to get data that is being sent as fast as the CMUCam can send it. Since the Midnight Prowlerbot is now using a connection to a laptop from the CMUCam instead, data is no longer polled, but is sent as fast as possible and the laptop buffers it up. The code presented is code that was used on the Midnight Prowlerbot when the CMUCam2+ was connected to the Basic Atom Pro instead of a laptop.


To get a color using the following code, the Midnight Prowlerbot generated a sound which permitted the user up to 10 seconds to place the object directly in front of the CMUCam. After the ten seconds expired, a sound was generated to let the user know that the color was being obtained. A final sound occurs to let the user know that the color was obtained. Here is the code:



The tracking code is very simple but is in a seperate subroutine for convenience. Note that since raw mode on the CMUCam2+ was configured for raw data that the data obtained through tracking will not be readable. The benefit of the raw data mode is that the TC response length will always be the same, whereas in non-raw mode, or readable mode, the response length varies depending on whether the values returned are single digit, two digit, or three digit. here is the code:


And finally, here is the main code that was used. Please note that functions such as searching for the object being tracked and other functions have been removed because this code is just showing how the previously posted subroutines are being used together to make the CMUCam2+ usable with the Basic Atom Pro. Besides, I found that using the CMUCam2+ built in tracking was much faster and more reliable than trying to respond quickly enough to overcome the communications delays between the CMUCam2+ and Basic Atom Pro and track reliably.

Instead, I eventually just used the built in tracking to automatically move the pan and tilt servos and acquired the values through the TC responses. This allowed tracking to be responsive and allowed the Basic Atom Pro to also be responsive since it wasn't bogged down trying to do tracking, which required even more communication. Here is the code:

Using Basic Atom Pro with CMUCam2+

Since formatting program code within the blog editor is such a challenge, I'm just including snapshots of the code. I would prefer otherwise so that it would be easy to copy-and-paste the code, but formatting the code properly for display just does not seem to be possible. Note that all of the code snippets were developed and tested on version 8.0.1.0 of the IDE for the Basic Atom Pro. Click on the code snippets to see the printout full-sized.

Here is the code that I used to initialize the CMUCam2+:

Next is calibration of the CMUCam2+ and here is the code for it:

Next, the CMUCam2+ is configured as follows:

At this point, the CMUCam2+ is ready to do things such as color tracking, motion tracking, histogram and other functions. The next posting will cover color tracking.

Using Basic Atom Pro with PING Ultrasonic Sensor

I've actually found a lot of information on using the PING ultrasonic sensor. There is even a forum topic in the Lynxmotion forums that goes through the whole process of developing code to get the Basic Atom Pro to work with the PING sensor located at http://www.lynxmotion.net/viewtopic.php?t=1819&postdays=0&postorder=asc&highlight=pro+ping+code&start=0

This code is posted here just to document what is used in the Midnight Prowlerbot. Here is the code that I used:

'Ultrasonic module - PING available from Lynxmotion or Parallax
Sonar_Pulse_Dat con P10

GetDistance

Low Sonar_Pulse_Dat
pulsout Sonar_Pulse_Dat, 10
RCTIME Sonar_Pulse_Dat, 1,rawDist
if rawDist > 65000 then
goto ErrorDist
endif
RCTIME Sonar_Pulse_Dat, 0, rawDist
PING_Scale.highword = 0
PING_Scale.lowword= 2260
cms = (rawDist */ PING_Scale ) / 2
goto GetDistanceExit
ErrorDist
cms = 0
GetDistanceExit

return

Please forgive the lack of proper indentation in the above code listing and previous code listings. I couldn't get the posting tool to cooperate enough to do proper indentations and I didn't want to take snapshots because I wanted people to be able to copy-and-paste the listings. The measurement result will be in the cms variable in centimeters.

The most significant difference between the code listed above for the PING and the code that is often listed on other websites for the Basic Atom non-Pro is the use of the rctime command instead of using pulsin. This is done because pulsin seems to be buggy on the Basic Atom Pro whereas rctime works fine. The pulsin bug is mentioned in several places on the Lynxmotion and Basic Micro forums.

The other difference in the above code and code that would be used on a non-Pro Basic Atom is that pulsout uses 10 for the time instead of 5. This is because the time is in 0.5 microsecond increments on the Basic Atom Pro compared to 1.0 microsecond increments on the Basic Atom.

This post is the last of three code listings for the different sensors currently used on the Midnight Prowlerbot. I still have a Memsic 2125 accelerometer that I could connect, but I can't see a real use for it at the moment on the Midnight Prowlerbot and I have my hands full with projects for the CMUCam2+. Posts from this point forward will be mostly about different projects with the CMUCam2+ and related code unless I decide to reconfigure the robot or add another sensor.

Using Basic Atom Pro with Sharp GP2D12 IR Sensor

Here is a listing of code used in the Midnight Prowlerbot for handling the Sharp GP2D12 infrared sensor readings.

'Infrared module - GP2D12 IR Sensor available from Lynxmotion
IR_LDat con P16 'AX2 (analog)
IR_RDat con P17 'AX3 (analog)

'Infrared reading conversion - this module is not linear and this compensates for it
IRconverttable bytetable 80,80,80,80,80,80,80,80,80,78,76,74,72,70,68,66,64,62,60, 59,58,57,55,53,52,51,50,49,48,47,45,43,42,41,40,39,38,37,35,33,
32,31,30,30,29,29,28,28,27,27,26,26,26,25,25,25,24,24,24,23,
23,22,22,21,21,20,20,20,19,19,18,18,18,17,17,16,16,16,15,15,
15,14,14,13,13,13,12,12,11,11,11,10,10,10,10,10,10,10,10,10

GetIRDistance

adin IR_RDat, IR_RRaw
IR_RFcms = tofloat(IR_RRaw) / 5.12
IR_Rcms = IRconverttable(toint IR_RFcms)
if IR_RRaw > 512 then
IR_Rcms = 99
endif

adin IR_LDat, IR_LRaw
IR_LFcms = tofloat(IR_LRaw) / 5.12
IR_Lcms = IRconverttable(toint IR_LFcms)
if IR_LRaw > 512 then
IR_Lcms = 99
endif

return

Notice that IR_RDat and IR_LDat do not use analog in pins that might be expected - they are using P16 and P17, not AX2 and AX3 as would be used on a Basic Atom. When I used AX2 and AX3, or even just 2 and 3 as in the manual, I couldn't get the sensors to work at all. Little did I realize that the adin command prefers a 'P' identified pin to work.

Since I rarely look for information on a device before using it, other than the manual or device sheet, I had no idea that the adin command had a quirk. It was after hours of frustration that I found a post on the Lynxmotion forums at http://www.lynxmotion.net/viewtopic.php?t=570&highlight=gp2d12 that described the pin identification problem.

Incidentally, the pin identifiers are mentioned in the Basic Atom Pro manual under the adin description, but what isn't mentioned is that if an 'AX#' identifier is used instead of a 'P#' identifier that the adin command will not work; however, the 'AX#' identifier works fine with the adin command on the Basic Atom non-Pro.

Oddly, I've had identifier issues with other commands also. It appears that using an assigned constant to identify a pin, such as using IR_RDat to identify P17, does not always work. For instance, serin does not seem to work with assigned constant identifiers, but works fine with 'P#' identifiers. Unfortunately, there is no indication that things aren't working as the code compiles and programs just fine.

I've even had a similar issue come up with 'if' statements only to find that not using an assigned constant identifier fixed the non-working code. This type of thing has happened on several occassions and failing to be aware of it caused frustration nearly to the point of forcible hair removal and uncontrollable mumbling. By the way, the identifier bug was on version 8.0.1.0 of the IDE. I'm not sure if it exists in the latest version.