Correlation is Not Causation Electrical Analysis of St Jude Implant Shows Normal Pacing

Correlation is Not Causation Electrical Analysis of St Jude Implant Shows Normal Pacing

St. Jude Merlin Error Indicators Are Not Evidence of Malfunction

Battle of the bands: Heres what we listened to while
writing this summary.

Heres an abbreviated technical analysis of some claims by Muddy Waters and St. Jude regarding pacemaker/defibrillator security. We will show you why correlation is not causation in the sense that a scary-looking screen is not a reliable indicator of a clinically relevant security problem. We did this analysis based on our experience over the last ten years analyzing pacemaker and defibrillator security and our experience building cardiac arrhythmia simulators for humanitarian pacemaker reuse. Read more at our ancient research website. Or see our index of previous blog posts on medical device security. This is a fun extracurricular activity for our team at the University of Michigan and Virta Labs, and we may post more thoughts before we return to our regular lives baking hearth breads and helping hospitals with cybersecurity risks.

The Muddy Waters report of August 25 showed a screenshot which they say shows an �apparent malfunction.� They also say that red error marks �are also indicators that the device is malfunctioning.� We were curious about these claims and decided to see if we could produce the same onscreen displays without causing any malfunction. This summary shows the screenshot is correlated with normal pacing and sensing, suggesting that the Muddy Waters report misinterprets clinical relevance of the screenshot.

Figure 1: Our experiment shows that a Merlin programmer screenshot from p. 17 of the Muddy Waters report is not supportive evidence of a successful attack. The top photo shows our reproduction of the Merlin programmer screen photo, but without causing changes to the pacing pulses. Our end-to-end oscilloscope measurements (bottom photo) show that pacing pulses continue normally despite the three benign alerts that are expected when not connected to cardiac tissue. 

Hypothesis: The Merlin programmer screen photo on page 17 of the Muddy Waters report is not supportive evidence of appearing �to have caused the device to pace at a rapid rate.�

Approach: Produce the same on-screen screen output, and externally measure electrical signals to test safety and effectiveness of pacing and sensing.

Result: We reliably produced the same screen output while the implant continued to pace normally.

Material: St. Jude Medical Fortify Assura ICD, Merlin programmer (software version 22.0.1 rev1)

Clinical validation: Verified by Dr. Thomas Crawford, a cardiologist and a clinical electrophysiologist at the University of Michigan Health Systems Frankel Cardiovascular Center.

Commentary:

To verify pacing, we configured the device to emit 40 bpm pacing pulses at 2.5 V, then connected a clipped lead (~20 cm) to the V (IS-1 Bi) sense/pace port, connected an oscilloscope to the clipped lead with 50 ? probes, and visually confirmed that the device was emitting 40 pulses per minute (Figure 1 bottom). To verify sensing, we used a signal generator to produce a 0.5 Hz square wave (consisting of 2 events, a rising then a falling edge, for a total of 1 event per second or 60 pbm) at 2 mV which we fed into the sense/pace port via the same lead; the programmer recognized a 60 bpm beat as expected. We tested other square-wave frequencies between 0.5 Hz and 2 Hz to verify that the sensing worked as expected.

To reproduce the markers that the Muddy Waters report highlights as indicators of a successful attack, we introduced benign electrical noise on the sense/pace port via the clipped lead by connecting the lead to a separately grounded oscilloscope (i.e., not grounded to the �can� of the device, which typically acts as ground). This noise was sufficient to trigger the �VS2� markers on the programmer screen, indicating that the device sensed a �ventricular beat.� While sampling the 40 bpm pacing output as described above, we reproduced the count of three alerts visible in the Muddy Waters report�s screen photo: two alerts from high impedance on two leads (since those were not connected to cardiac tissue), and one indicating �ventricular noise reversion.� The pacing and sensing continued to function normally. ?

The team from the University of Michigan and Virta Labs is continuing to investigate the contrasting claims by Muddy Waters and St. Jude Medical. To receive notifications of updates, follow the Archimedes Center for Medical Device security @ARC_MedSec and @DrKevinFu on Twitter. Virta Labs also plans to issue a separate white paper.

{ Read More }

Creating a MySQL db on Ubuntu as a normal user

Creating a MySQL db on Ubuntu as a normal user

Lately I tried to create a MySQL db on Ubuntu (version 11 which has MySQL 5.1 preinstalled). I was logged in under my normal username but I got a surprise when running the mysql_install_db command.

 $ /usr/bin/mysql_install_db --datadir=./mysql/data Installing MySQL system tables... 130806 22:17:21 [Warning] Cant create test file /home/andreash/mysql/data/andreas-Ub-2.lower-test 130806 22:17:21 [Warning] Cant create test file /home/andreash/mysql/data/andreas-Ub-2.lower-test Installation of system tables failed! Examine the logs in ./mysql/data for more information. ... 

There were not log files though and checking directories and permissions didnt reveal any problems.
So I started to search and found that Ubuntu uses a security mechanism called apparmor which can be used to control certain aspects of an application.
In regards to MySQL that means that there exists a MySQL profile which defines which directories can be accessed (and how) by the MySQL programs. The profile for the daemon mysqld is defined in /etc/apparmor.d/usr.sbin.mysqld and looks like this:

 # Last Modified: Tue Jun 19 17:37:30 2007 #include <tunables/global> /usr/sbin/mysqld { #include <abstractions/base> #include <abstractions/nameservice> #include <abstractions/user-tmp> #include <abstractions/mysql> #include <abstractions/winbind> capability dac_override, capability sys_resource, capability setgid, capability setuid, network tcp, /etc/hosts.allow r, /etc/hosts.deny r, /etc/mysql/*.pem r, /etc/mysql/conf.d/ r, /etc/mysql/conf.d/* r, /etc/mysql/*.cnf r, /usr/lib/mysql/plugin/ r, /usr/lib/mysql/plugin/*.so* mr, /usr/sbin/mysqld mr, /usr/share/mysql/** r, /var/log/mysql.log rw, /var/log/mysql.err rw, /var/lib/mysql/ r, /var/lib/mysql/** rwk, /var/log/mysql/ r, /var/log/mysql/* rw, /{,var/}run/mysqld/mysqld.pid w, /{,var/}run/mysqld/mysqld.sock w, /sys/devices/system/cpu/ r, # Site-specific additions and overrides. See local/README for details. #include <local/usr.sbin.mysqld> } 

So in order to enable MySQL to access a subdirectory of my $HOME I had to edit the file as root (sudo vi ...) and add this line to the list (I put it right under the /sys/devices line)

 /home/andreas/mysql/** rw, 

The apparmor man page explains the syntax and attributes in detail. For my purposes it suffices to know that ** stands for the directory and all subdirectories underneath and rw is of course read/write.

Then this new profile needs to be activated replacing the old one via

 $ sudo apparmor_parser -rv /etc/apparmor.d/usr.sbin.mysqld Replacement succeeded for "/usr/sbin/mysqld". 

Finally running the MySQL program again did create the databases.

 Installing MySQL system tables... OK Filling help tables... OK To start mysqld at boot time you have to copy support-files/mysql.server to the right place for your system PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! To do so, start the server, then issue the following commands: ... 

---

Not knowing much about apparmor yet I wonder how one would go about to allow all users (on a bigger multi-user server) to use MySQL or any other application which is secured in the same way. It would be impractical to add all users home directories to the profile file so I guess there must be some shortcut. This needs more reading.

{ Read More }