Tuesday, October 14, 2014

Periodicity, or ShellShock, the Gift That Keeps on Giving

Oxford definition of periodicity: The quality or character of being periodic; the tendency to recur at intervals: the periodicity of the sunspot cycle.

Which is fine, so far as it goes, but we need to go a bit further.

In Linux-land, if we need something to occur periodically, with a high degree of certainty, we use the cron facility, which dates back to classic UNIX, and time out of mind. We also turn off any modifiers that add a random delay. Random delays can be a useful feature if we do not want, for instance, tens of thousands of systems all hitting a server at once. But sometimes that is absolutely what we do want. For instance, random delays can really mess with intrusion prevention systems that alarm on network traffic that occur outside of narrow windows. Well, it messes with the people that have to respond, anyway. The IPS itself, being software, does not care.

Straight off, we have two things to periodically (terrible joke) think about.
  1. Strict periodicity
  2. Periodicity with random delay

There are at least two additional things we might want to consider. Let us get the more unusual (but tremendously useful) case out of the way first.

Suppose that we want something to happen n number of times in a time span of length l. Furthermore, we want the interval between n, n+1, etc., to not be predictable. If you can't imagine the use for such a thing, I invite you to consider Quality of Service (QoS), which can be driven into the code of distributed computation systems as well as contractual agreements that humans may be more familiar with. These can be couched in terms of length of time (l), so being able to specify l, and the number of tests n you want to run in each l, is useful. We might also want n to vary, and to specify the allowed range of n. It's a hedge against cheating, and can yield better statistics. In software, you can carry this to extremes.

Now we have three items in our list.
  1. Strict periodicity
  2. Periodicity with random delay
  3. Periodicity with multiple random delays

To the best of my knowledge, there is no facility in any bog-standard OS that supports this, out of the box. That is a problem, because it has been coded, ad-hoc, innumerable times.

Now, let us add a fourth category. Suppose we want to do something at some point in the future, perhaps even repeatedly, but not on a periodic basis. I do this quite a bit. Some software package or OS is due to be updated, and I want to tell the system to get it at midnight.

In Unix or Linux, we have the 'at' facility for this. I can literally use the term 'midnight'. Or noon. Even teatime, though I don't have to limit myself to those times. I can queue the job months in advance. It's wonderful. I keep a text file of 'at' jobs. The second time I need to do something in the future, it goes into that file. My theory is that if I have needed to do it more than once, reviewing that file might remind me of something that needs to happen. It only takes a moment, and has saved me in the past. I even use 'at' jobs in that file to notify me of conferences. That is very much off-the-wall; sane people don't do that. But it is also a measure of the usefulness of the 'at' facility.

The addition of 'at' gives us the following list.
  1. Strict periodicity
  2. Periodicity with random delay
  3. Periodicity with multiple random delays
  4. Aperiodic

And that is where the bash ShellShock vulnerability bites, yet again. It turns out that the fix for ShellShock broke 'at'.

Think about this. ShellShock was announced (it may, of course, have been known previously) on 9/24. OpenSSH sshd, mod_cgi and mod_cgid in Apache, and various DHCP clients were affected. At least three system calls (of which Linux has far too many) can be vulnerable. In severity, this is comparable to HeartBleed. But it wasn't until 10/4 or so, in the neighborhood of nine days, that a fix for a problem with a major Linux job scheduling facility became available for at least one common Linux distribution.

I could go on and on about this; I have not even scratched the surface. But it is getting late, lunch never happened, and I am one hungry unit.


No comments:

Post a Comment

Thanks for your comment; communities are not built without you.

But note than comments on older posts usually go into a modertion queue. It keeps out a lot of blog spam. Weird links to Web sites hosting malware, marketing nonsense, etc.

I really want to be quick about approving comments in the moderation queue. When I think I won't manage that, I will turn moderation off, and sweep up the mess as soon as possible.

If you find comments that look like blog spam, they likely are. As always, be careful of what you click on. I may have had moderation off, and not yet swept up the mess.