mark :: blog

<< prev [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ] next >>


It came as no surprise when Microsoft admitted to quiet security patching. We knew many years ago that they did this: not counting extra vulnerabilities that were found internally or by researchers contracted to work for them. For closed source, single vendor software, this isn't too big of a deal - it's not like the user has a choice if they need to update some application to address one critical vulnerability or 20.

When you look back, before they admitted to this practice, Microsoft actively used vulnerability counts in reports as a tool to discredit the security of open source distributions. Famously even Steve Ballmer participated in counting vulnerabilities using candy.

In other news, the Red Hat Enterprise Linux 4 risk report we release each year has been published (PDF). This whitepaper looks at the state of security for the first five years of Red Hat Enterprise Linux 4 from its release on February 15th, 2005. It includes metrics, key vulnerabilities, and the most common ways users were affected by security issues.

"Red Hat knew about 52% of the security vulnerabilities that we fixed in advance of them being publicly disclosed. The average time between Red Hat knowing about an issue and it being made public was 22 days (median 10 days).... A default installation of Red Hat Enterprise Linux 4 AS was vulnerable to 14 critical security issues over the entire five years. "


Red Hat Enterprise Linux 5.5 was released at the end of March 2010, just under 7 months since the release of 5.4 in September 2009. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates we've made in that time, specifically for Red Hat Enterprise Linux 5 Server.

Errata count

The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.4, up to and including the 5.5 release, broken down by severity. I've split it into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what you have installed or removed.

missing graph

So for a default install, from release of 5.4 up to and including 5.5, we shipped 52 advisories to address 140 vulnerabilities. 5 advisories were rated critical, 14 were important, and the remaining 33 were moderate and low.

Or, for all packages, from release of 5.4 to and including 5.5, we shipped 75 advisories to address 187 vulnerabilities. 6 advisories were rated critical, 18 were important, and the remaining 51 were moderate and low.

Critical vulnerabilities

The 6 critical advisories were for 3 different packages. Given the nature of the flaws, ExecShield protections in RHEL5 should make exploiting the memory flaws harder.

  1. Four updates to Firefox (September 2009, October 2009, December 2009, February 2010) where a malicious web site could potentially run arbitrary code as the user running Firefox.
  2. An update to kdelibs (November 2009), where a malicious web site could potentially run arbitrary code as the user running the Konqueror browser. kdelibs is not a default installation package.
  3. An update to krb5, the Kerberos network authentication system (January 2010), where a remote KDC client could cause a crash or run arbitrary code as root. This issue only affected users that have configured and enabled krb5.

Updates to correct 24 out of the 25 critical vulnerabilities were available via Red Hat Network either the same day, or up to one calendar day after the issues were public. The update to fix Konqueror took us 4 calendar days.

Overall, for Red Hat Enterprise Linux 5 since release to date, 98% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.

Other significant vulnerabilities

Red Hat Enterprise Linux since 5.2 contained backported patches from the upstream Linux kernel to add the ability to restrict unprivileged mapping of low memory, designed to mitigate NULL pointer dereference flaws. In the last risk report we mentioned it was found that this protection was not sufficient, as a system with SELinux enabled was more permissive in allowing local users in the unconfined_t domain to map low memory areas even if the mmap_min_addr restriction is enabled. This is CVE-2009-2695 and was addressed in a kernel update in November 2009.

Previous updates

To compare these statistics with previous update releases we need to take into account that the time between each update is different. So looking at a default installation and calculating the number of advisories per month gives the results illustrated by the following chart:

missing graph

This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.

See also: 5.3 to 5.4, 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.


And not because she's set the alarm for the wrong time, or used a 'crazy frog' sound theme, but because it had a remote root exploit. It's fixed now.

It all started when I bought her a Chumby for Christmas. A Chumby is a little bedside device that can act as an alarm clock as well as running flash-lite applets. What made it especially appealing is that you can write your own applets if you want, and the whole thing is Linux-based and designed to be hackable: they correctly abide by the GPL and have their sources available, you can build and install your own software, you can even enable ssh and have a remote shell if you want to. And with NTP the clock is always at the right time, since I really don't like having out-of-sync clocks around the house.

So it was time to connect another device to my wireless network: a device designed to be left on and permanently connected to the network, and having a connected microphone, in the bedroom. A quick look around the OS and I found that it had a web server accessible by default, and a pair of CGI scripts, written in shell script, running as root, that didn't correctly escape their input. (Hint: writing secure CGI scripts in shell is non-trivial).

With a bit of careful manipulation (to get around some character handling in the code) I had a remote root shell on a default Chumby and could stream audio from the microphone remotely. Oops. Not too big a deal though as it's unlikely you're going to have it directly connected to the internet, although with some social engineering, if you know someone with a Chumby, you could do a cunning cross-site scripting attack and get a reverse shell that way.

I contacted the Chumby folks and they dealt with this like an ideal vendor; acknowledging the issue, keeping in contact, and doing a security update. Good for them. I like this device and vendor so much I'm going to buy another Chumby, and a few colleagues from work are too.

But how many other devices do we connect to our networks without thinking about them, and how many folks outside of the security paranoid have properly secured and segmented wireless networks? I've got a IP wireless network CCTV camera and a VOIP phone system both which seem to be running Linux (and both which seem to have vulnerabilities) to worry about next although harder since both are closed systems which haven't released their source.

So for CVE database: CVE-2010-0418 is "Chumby One before 1.0.4 and Chumby Classic before 1.7.2 allows remote attackers to execute arbitrary commands via shell metacharacters in a carefully crafted request to the web interface". Reported 29 Dec 2009, vendor responded 29 Dec 2009, tested fix 3 Feb 2010, public and updates 4 Mar 2010.


The 2010 CWE/SANS Top 25 Most Dangerous Programming Errors was published today listing the most widespread issues that lead to software vulnerabilities.

During the creation and review of the list we spent some time to see how closely last years list matched the types of flaws we deal with at Red Hat. We first looked at all the issues that Red Hat fixed across our entire product portfolio in the 2009 calendar year and filtered out those that had the highest severity. All our 2009 vulnerabilities have CVSS scores, so we filtered on those that have a CVSS base score of 7.0 or above[1].

There were 22 vulnerabilities that matched, and we mapped each one to the most appropriate CWE. This gives us 11 flaw types which led to the most severe flaws affecting Red Hat in 2009:

CWECWE DescriptionCWE/SANS
top 25?
Number of
Vulnerabilities
CWE-476NULL Pointer DereferenceNo (on cusp)6
CWE-120Buffer Copy without Checking Size of InputYes3
CWE-129Improper Validation of Array Index Yes3
CWE-131Incorrect Calculation of Buffer Size Yes3
CWE-78OS Command InjectionYes1
CWE-285Improper Access Control (Authorization)Yes1
CWE-362Race ConditionYes1
CWE-330 Use of Insufficiently Random Values No (on cusp)1
CWE-590Free of Memory not on the HeapNo1
CWE-672Use of a Resource after Expiration or ReleaseNo (on cusp)1
CWE-772Missing Release of Resource after Effective LifetimeNo (on cusp)1

10 of the 11 CWE are mentioned in the 2010 CWE/SANS document, although 4 of them are on "the cusp" and didn't make it into the top 25.

This quick review shows us that 2009 was the year of the kernel NULL pointer dereference flaw, as they could allow local untrusted users to gain privileges, and several public exploits to do just that were released. For Red Hat, interactions with SELinux prevented them being able to be easily mitigated, until the end of the year when we provided updates. Now, in 2010, the upstream Linux kernel and many vendors ship with protections to prevent kernel NULL pointers leading to privilege escalation. So although 2009 was the year where CWE-476 mattered to Linux administrators, it didn't make the SANS/CWE top 25 as this flaw type should not lead to severe issues (as long as the protections remain sufficient).

Here is a breakdown with the complete data set to show the CVSS scores and packages affected:

CVECWEtop 25?CVSS
base
Fixed in
CVE-2008-5182 CWE-362Yes 7.2Red Hat Enterprise Linux 5 (kernel)
CVE-2009-0065 CWE-129Yes 8.3Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-0692 CWE-120Yes 8.3Red Hat Enterprise Linux 3,4 (dhcp)
CVE-2009-0778 CWE-772No (on cusp) 7.1Red Hat Enterprise Linux 5 (kernel)
CVE-2009-0846 CWE-590No 9.3Red Hat Enterprise Linux 2.1, 3 (krb5) [2]
CVE-2009-1185 CWE-131Yes 7.2Red Hat Enterprise Linux 5 (udev)
CVE-2009-1385 CWE-129Yes 7.1Red Hat Enterprise Linux 3,4,5,MRG (kernel)
CVE-2009-1439 CWE-131Yes 7.1Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-1579 CWE-78Yes 7.5Red Hat Enterprise Linux 3,4,5 (squirrelmail)
CVE-2009-1633 CWE-131Yes 7.1Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-2406 CWE-120Yes 7.2Red Hat Enterprise Linux 5 (kernel)
CVE-2009-2407 CWE-120Yes 7.2Red Hat Enterprise Linux 5 (kernel)
CVE-2009-2692 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 3,4,5,MRG (kernel)
CVE-2009-2694 CWE-129Yes 7.5Red Hat Enterprise Linux 3,4,5 (pidgin)
CVE-2009-2698 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 3,4,5 (kernel)
CVE-2009-2848 CWE-672No (on cusp) 7.2Red Hat Enterprise Linux 3,4,5,MRG (kernel)
CVE-2009-2908 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 5 (kernel)
CVE-2009-3238 CWE-330No (on cusp) 7.8Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-3290 CWE-285Yes 7.2Red Hat Enterprise Linux 5 (kvm)
CVE-2009-3547 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 3,4,5,MRG (kernel)
CVE-2009-3620 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 4,5,MRG (kernel)
CVE-2009-3726 CWE-476No (on cusp) 7.2Red Hat Enterprise Linux 5,MRG (kernel)

[1] NIST NVD rate vulnerabilities as "High" severity if they have a CVSS base score of 7.0-10.0. This ends up excluding flaws in web browsers such as Firefox which can have a maximum CVSS base score of 6.8.

[2] Red Hat Enterprise Linux 4 and 5 were also affected by this vulnerability, but with a lower CVSS base score of 4.3, due to the extra runtime pointer checking.


There have been quite a few stories over the last couple of weeks about the NULL character certificate flaw, such as this one from The Register.

The stories center around how open source software such as Firefox was able to produce updates to correct this issue just a few days after the Blackhat conference, while Microsoft still hasn't fixed it and are "investigating a possible vulnerability in Windows presented during Black Hat".

But the actual timeline is missing from these stories.

The NULL character certificate flaw (CVE-2009-2408) was actually disclosed by two researchers working independantly who both happened to present the work at the same conference, Blackhat, in July this year. Dan Kaminsky mentioned it as part of a series of PKI flaws he disclosed. Marlinspike had found the same flaw, but was able to demonstrate it in practice by managing to get a trusted Certificate Authority to sign such a malicious certificate.

The flaw was no Blackhat surprise; Dan Kaminsky actually found this issue many months ago and responsibly reported the issues to vendors including Red Hat, Microsoft, and Mozilla. We found out about this issue on 25th February 2009 and worked with Dan and some of the upstream projects on these issues in advance, so we had plenty of time to prepare updates and this is why we were able to have them ready to release just after the disclosure.


We keep all our friends and family contacts in a single text file in vCard format. We sync this file to our phones (mobile and house DECT phones) and home automation system (for caller ID and phone book). I also print out a copy to take when travelling. Except I rarely print out an update as I've failed to find any useful program to pretty print the contacts. Previously I used a quick hack script in perl to convert the vcard entries to HTML, but it wasn't clever enough to handle page breaks and needed manual setting all the margins and page sizes correctly. I like to print it to fit in my paper planner, a Compact size Franklin Covey planner system.

I've been using Scribus for a few months, mostly for our wedding invites and stationary, and spotted that Scribus had a Python API. So a few hours later and out has popped a Python script you can use to pretty print a vCard vcf file, handling page breaks, images, and large margins to skip the hole punches.

Here is an extract from a sample vCard file:

BEGIN:VCARD
ADR;TYPE=work:;;10 Downing Street;London;SW1A 2AA
TEL;TYPE=fax:+44 2079 250918
NICKNAME:Prime Minister
FN:Gordon Brown
N:Brown;Gordon
PHOTO;VALUE=URI:https://www.number10.gov.uk/wp-content/uploads/pm-official-pic-234x300.jpg
VERSION:3.0
END:VCARD

You'll need a few things:

  1. a sample vCard file or your own one
  2. vcf2scribus.py script (version 1.0)
  3. A recent version of Scribus. 1.3.5 works, but earlier ones will not.
  4. You'll also need the python vobject library installed if you haven't already got it

Use the "Script" "Execute Script" option, find and select vcf2scribus.py and hopefully you'll end up with something like this:

You can then save it as a pdf or print it direct.

The script is a bit of a hack and has hard-coded page sizes, fonts, margins, vcard sections used, and so on. But I figure it might save someone a couple of hours and only needs a bit of modification to suit. It would be fairly easy to extend the script to use the Scribus API to let folks select the vcard file, page sizes, fonts, and things. Bonus points if you fix it to figure out the final sizes of the images and right align them. This is my second ever python program so no sniggering at the code!


I've written about a lot of technical things in my blog over the years, but not so much that is personal. However nothing is more important to me than a special date last month, 8th August 2009, when I got married to Tracy.

I met Tracy via ICQ over nine years ago and we've been partners for eight, so it was about time we got around to getting married. We both wanted a castle wedding, and as Monty Python fans we couldn't resist Doune Castle, a restored 14th century stronghold not far from Glasgow which was used in the "Holy Grail" film.

Copyright Rhoddy Stewart Photography Copyright Rhoddy Stewart Photography Copyright Rhoddy Stewart Photography Copyright Rhoddy Stewart Photography

So we couldn't resist a few Python moments, with coconuts, the French guards door scene, and the killer rabbit of Caerbannog. Run away!

Copyright Rhoddy Stewart Photography Copyright Rhoddy Stewart Photography Rabbit of Caerbannog :

Our cake topper was commissioned from an artist in Brazil we found via flickr.

Copyright Rhoddy Stewart Photography

All the artwork including invitations, day plans, and place cards was drawn and created by ourselves using Inkscape and Scribus on Fedora, I'm going to blog about that and share the files when I have some more time next month.

The only issues we had on the day where with the cake which the supplier (Marks and Spencers) lost part of and were unable to replace with the right cake, and a poor substitute DJ (our chosen DJ ended up in hospital just before the event).

Everything else went amazingly well and to plan and despite the poor August weather in Scotland this year managed great weather with only a light shower as guests were leaving the castle.


Red Hat Enterprise Linux 5.4 was released today, just over 7 months since the release of 5.3 in January 2009. So let's use this opportunity to take a quick look back over the vulnerabilities and security updates we've made in that time, specifically for Red Hat Enterprise Linux 5 Server.

Errata count

The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server as if you installed 5.3, up to and including the 5.4 release, broken down by severity. I've split it into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what you have installed or removed.

missing graph

So for a default install, from release of 5.3 up to and including 5.4, we shipped 51 advisories to address 166 vulnerabilities. 8 advisories were rated critical, 18 were important, and the remaining 25 were moderate and low.

Or, for all packages, from release of 5.3 to and including 5.4, we shipped 78 advisories to address 251 vulnerabilities. 9 advisories were rated critical, 28 were important, and the remaining 41 were moderate and low.

Critical vulnerabilities

The 9 critical advisories were for just 3 different packages. In all the cases below, given the nature of the flaws, ExecShield protections in RHEL5 should make exploiting these memory flaws harder.

  1. Seven updates to Firefox (February, March 4th, March 27th, April 21st, April 27th, June, July ) where a malicious web site could potentially run arbitrary code as the user running Firefox.
  2. An update to kdelibs (June), where a malicious web site could potentially run arbitrary code as the user running the Konqueror browser. kdelibs is not a default installation package.
  3. An update to the NSS library (July), where a service could present a malicious SSL certificate causing a heap overflow which could potentially run arbitrary code as the user running a browser such as Firefox.

Updates to correct all of these critical vulnerabilities were available via Red Hat Network either the same day, or up to one calendar day after the issues were public.

In fact for Red Hat Enterprise Linux 5 since release and to date, every critical vulnerability has had an update available to address it available from the Red Hat Network either the same day or the next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest during this period were several NULL pointer dereference kernel issues. NULL pointer dereference flaws in the Linux kernel can often be easily abused by a local unprivileged user to gain root privileges through the mapping of low memory pages and crafting them to contain valid malicious instructions:

Red Hat Enterprise Linux since 5.2 has contained backported patches from the upstream Linux kernel to add the ability to restrict unprivileged mapping of low memory, designed to mitigate NULL pointer dereference flaws. However it was found that this protection was not sufficient, as a system with SELinux enabled is more permissive in allowing local users in the unconfined_t domain to map low memory areas even if the mmap_min_addr restriction is enabled. This is CVE-2009-2695 and will be addressed in a future kernel update.

Mitigations

Red Hat Enterprise Linux 5 shipped with a number of security technologies designed to make it harder to exploit vulnerabilities and in some cases block exploits for certain flaw types completely. From 5.3 to 5.4 there were three flaws blocked that would otherwise have required critical updates:

Previous updates

To compare these statistics with previous update releases we need to take into account that the time between each update is different. So looking at a default installation and calculating the number of advisories per month gives the results illustrated by the following chart:

missing graph

This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.

See also: 5.2 to 5.3, 5.1 to 5.2, and 5.0 to 5.1 risk reports.


In his Black Hat paper and presentation yesterday, Dan Kaminsky highlighted some more issues he has found relating to SSL hash collisions and other PKI flaws. The video of the presentationis online now, so I'm sure the PDF paper will follow shortly. Some of these issues affect open source software, and some parts have already been addressed, so here is a quick summary including CVE names of the applicable bits:

MD2 signature verification

The first issue is that many web browsers still accept certificates with MD2 hash signatures, even though MD2 is no longer considered a cryptographically strong algorithm. This could make it easier for an attacker to create a malicious certificate that would be treated as trusted by a browser. It turns out that there are not many valid MD2 hash certificates around any more, and the main one that does exist is at the trusted root level anyway (and there is actually no need for a crypto library to verify the self-signature on a trusted root). So most vendors have chosen to address this issue by disabling MD2 completely for certificate verification. This is allocated CVE name CVE-2009-2409 ( single name for all affected products).

There is no immediate panic to address this issue as a critical security issue, as in order for it to be exploited an attacker still has to create a MD2 collision with this root certificate; something that is as of today still a significant amount of effort.

My CVSS v2 base score for CVE-2009-2409 would be 2.6 (AV:N/AC:H/Au:N/C:N/I:P/A:N)

Differences in Common Name handling

This issue is about how Common Names are checked for validity by applications. For example if a server presents a certificate with two CN entries, how does the app validate those. Does it use the first one, the last one, or all of them?

Leading 0's in Common Name handling

The second issue is all about inconsistencies in the interpretation of subject x509 names in certificates. Specifically "issue 2b, subattack 1" is where a malicious certificate can contain leading 0's in the OID. The idea is that an attacker could add in some OID into a certificate that, when handled by the Certificate Authority, would appear to be some extension and ignored, but when handled by OpenSSL would appear to be the Common Name OID. So the attacker would present the certificate to a client application and it might think that the OID is actually a Common Name, and accept the certificate where it otherwise should not.

OID overflow in Common Name handling

"issue 2b, subattack 2" is where a malicious certificate can have a very large integer in the OID. The idea is that an attacker could add in some OID into a certificate that, when handled by the CA, would appear to be some extension and ignored, but when handled by OpenSSL would overflow and appear to be the Common Name OID. So the attacker would present the certificate to a client application using OpenSSL and it might think that the OID is actually a Common Name, and accept the certificate where it otherwise should not.

NULL bytes in Common Name handling

"issue 2, attack 2c" is regarding NULL terminators in a Common Name field. If an attacker is able to get a carefully-crafted certificate signed by a Certificate Authority trusted by a browser, the attacker could use the certificate during a man-in-the-middle attack and potentially confuse the browser into accepting it by mistake.

My CVSS v2 base score for CVE-2009-2408 would be 4.3 (AV:N/AC:M/Au:N/C:N/I:P/A:N)

OpenSSL 'compat mode' subject name injection

"issue 2d" is how the OpenSSL command line utility will output unescaped subject X509 lines to standard output. So if some utility runs the openssl application from the command line and parses the text output, and if an attacker can craft a malicious certificate in such a way they fool a CA into signing it, they could present it to the utility and possibly fool that utility into thinking fields were different to what they actually are, perhaps allowing the certificate to be accepted as legitimate.

OpenSSL ASN1 printing crash

Also mentioned in the paper is a flaw in the filtering modes when a two or four byte wide character set is asked to be filtered.

My CVSS v2 base score for CVE-2009-0590 would be 2.6 (AV:N/AC:H/Au:N/C:N/I:N/A:P)


A few years ago I automated the treadmill in our guest room as a way of motivating Tracy and I to keep fit. The treadmill sent us emails when we used it, and the touch panels around the house showed how much we'd used it in the last week and month. This worked really well for some time; until the point we realised if we both agreed to stop using it on the same day then there would be no competition, no winner, no loser, and neither us would feel bad.

Last winter the Red Hat video team came to my house to record some footage for both internal and external use. On one of the internal videos they look at my home automation system, point the camera at a wall tablet, and figure out that I'd not used my treadmill in over two years. So there were really two options (1) remove the year from the display so it would never look like we were slacking for more than a year, or (2) find a way to get motivated again.

Recently we both started using Twitter, so it seemed like a natural progression to hook the treadmill to twitter and have it publicly embarrass us for slacking off.

So the treadmill now has it's own twitter page.

We called it 'twedmill' ('tweadmill' perhaps is more correct, but just sounds like a factory that weaves twead jackets). Here is how it works:

twedmill the 1wire twittering treadmill The treadmill itself is pretty standard; it's from Trimline and has a fancy computer. When I looked inside and saw a PIC I was tempted to interface direct to the computer, but didn't really have the time to get around to that. Although the treadmill does things like have a variable incline and measurement of heart rate, all I really care about it making sure we were using it, for how long, and how far we got.

twedmill the 1wire twittering treadmill Under a cover in the base are the PWM controllers, motors, and the belt drive to the treadmill deck. The treadmill itself measures the belt speed by having a single magnet on the wheel and a small sensor next to it, one revolution giving one pulse. So to keep things simple I just hot-glued a spare reed switch I had around so the same magnet would trigger it. The reed switch happily copes with the treadmill even on top speed, so no real need for anything more fancy.

I didn't have anything that could accurately measure the diameter of the roller, so by counting pulses at various speeds and comparing to the onboard display it worked out at 8122 pulses/revolutions per (uk) mile (so that's about 198mm of travel per pulse, making the diameter of the roller about 63mm).

twedmill the 1wire twittering treadmill twedmill the 1wire twittering treadmill I use a 1-wire network in the house to measure temperatures, watch the doorbell, and control the central heating system, so I wanted to use the same system to deal with the treadmill. So the reed switch connects to a DS2423 counter (Unfortunately it seems the DS2423 is discontinued now). The DS2423 was only available in a surface-mount package, so I found some converters on ebay to save having to design a PCB just for three components. The DS2423 connects into a 1-wire hub in node0, then to a 1-wire USB adapter on our main server, currently running Fedora 10.

The software used in based on the source code from 'digitemp' as it includes code in cnt1d.c to read the counter values. Every ten seconds the jabber treadmill bot switches to the right network segment on the 1-wire hub then polls the counter of the DS2423 to see if the treadmill has moved. Once the treadmill has stopped moving for a while the software stores the total distance travelled and time in a database, sends an email, and uses the perl Net::Twitter module to post a mesage to twitter. (It can also draw a graph showing speed over time, but that turned out to be not very interesting)

For the future I'd quite like to hook directly into the treadmill computer, perhaps giving two way control of the treadmill programs, as well as recording the incline and heart rate. Another idea has been to use the current treadmill speed to decide which music video to play next based on bpm (the tv is connected to an old XBOX running XMBC so could easilly be remotely controlled to switch videos). Or perhaps link it to google streets for a virtual jog through some random town. Finally, you currently have to select who is using the treadmill before (or very quickly after) using it using the touch panels in the house; which seems like a good excuse to play with some RFID in our shoes, perhaps also using that to select a playlist of music videos per person.

<< prev [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ] next >>

Hi! I'm Mark Cox. This blog gives my thoughts and opinions on my security work, open source, fedora, home automation, and other topics.