The RISKS Digest
Volume 26 Issue 20

Wednesday, 10th November 2010

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


Stephen Colbert's voting machine satire
J. Alex Halderman, Hacking DC, Freedom to Tinker
Trust the Vote—not!
Rebecca T Mercuri
Voting machines selecting default candidates
Lauren Weinstein
Data mining Facebook reveals when you're most likely to be dumped
David McCandless via Mark Thorson
Getting Crypto Wrong
Neal Ungerleider via Gene Wirchenko
Something has been going right in the fight against spam, viruses, ...
Jonathan Kamens
Rise of VoIP systems open new market for exploitation
Dennis van Dok
Banks Rush to Fix Security Flaws in Wireless Apps
Spencer E. Ante via Monty Solomon
U.S. Daylight Saving Time ends with bug in iOS4
Tony Finch
The most expensive SW bug in recorded human history
Henry Baker
Crowdsourcing videosurveillance
Jeremy Epstein
Student Password Extension
Geoff Kuenning
Risks of listening to cries for help
Nick Brown
Remote starter risk
Cellphone's Missing Dot Kills Two People, Puts Three More in Jail
Gene Wirchenko
Texting Stinks?
Gene Wirchenko
Re: Medical Errors
Re: Risks of not following standards
Jerry Leichter
Info on RISKS (comp.risks)

Stephen Colbert's voting machine satire

"Peter G. Neumann" <>
Wed, 3 Nov 2010 12:17:22 PDT

PGN-ed excerpts from a wonderful parody toward the end of The Colbert
[coal-bear] Report on Comedy Central on the evening of Election Day in the

  Now, there have been reports of voting machine irregularities ...  For
  instance in Jackson County, West Virginia, machines have actually changed
  votes, which would explain why `Candidate Page error 404' is now headed
  to the House of Representatives [with 93% of the vote].  Congratulations!

  Now, for more on this very disturbing story, let's go to where the polls
  are still open—Kalua, Hawaii.  ...  [with Colbert inside the voting
  machine, behind the touchscreen, with the camera able to see the voter!]

  Colbert:  Hello voter!
  Voter:  Hey, Steven Colbert is in my voting machine!
  Colbert:  Shhh.  Have you seen anything suspicious?

Colbert does a lovely Alex Halderman imitation, flipping the voter's
straight-party selections to the other party.

J. Alex Halderman, Hacking DC, Freedom to Tinker

"Peter G. Neumann" <>
Tue, 5 Oct 2010 18:47:05 PDT

  Freedom to Tinker
    ... is your freedom to understand, discuss, repair, and modify the
    technological devices you own.
  J. Alex Halderman, Hacking the D.C. Internet Voting Pilot, 5 Oct 2010

The District of Columbia is conducting a pilot project
<> to allow overseas and military voters to
download and return absentee ballots over the Internet. Before opening the
system to real voters, D.C. has been holding a test period in which they've
invited the public to evaluate the system's security and usability.

This is exactly the kind of open, public testing that many of us in the
e-voting security community—including me—have been encouraging vendors
and municipalities to conduct. So I was glad to participate, even though the
test was launched with only three days; notice. I assembled a team from the
University of Michigan, including my students, Eric Wustrow
<> and Scott Wolchok <>, and
Dawn Isabel, a member of the University of Michigan technical staff.

Within 36 hours of the system going live, our team had found and
exploited a vulnerability that gave us almost total control of the
server software, including the ability to change votes and reveal
voters' secret ballots. In this post, I'll describe what we did, how we
did it, and what it means for Internet voting.

D.C.'s pilot system

The D.C. system is built around an open source server-side application
<> developed in partnership with
the TrustTheVote project <>. Under the hood, it
looks like a typical web application. It's written using the popular Ruby on
Rails framework and runs on top of the Apache web server and MySQL database.

Absentee overseas voters receive a physical letter in the mail instructing
them to visit a D.C. web site,, and log in with a
unique 16-character PIN. The system gives voters two options: they can
download a PDF ballot and return it by mail, or they can download a PDF
ballot, fill it out electronically, and then upload the completed ballot as
a PDF file to the server. The server encrypts uploaded ballots and saves
them in encrypted form, and, after the election, officials transfer them to
a non-networked PC, where they decrypt and print them. The printed ballots
are counted using the same procedures used for mail-in paper ballots.

      A small vulnerability, big consequences

We found a vulnerability in the way the system processes uploaded
ballots. We confirmed the problem using our own test installation of the
web application, and found that we could gain the same access privileges
as the server application program itself, including read and write
access to the encrypted ballots and database.

The problem, which geeks classify as a shell-injection vulnerability, has to
do with the ballot upload procedure
When a voter follows the instructions and uploads a completed ballot as a
PDF file, the server saves it as a temporary file and encrypts it using a
command-line tool called GnuPG <>.  Internally, the
server executes the command gpg with the name of this temporary file as a
parameter: |gpg [] /tmp/stream,28957,0.pdf|.

We realized that although the server replaces the filename with an
automatically generated name (stream,28957,0) in this example), it keeps
whatever file /extension/ the voter provided. Instead of a file ending in
.pdf, we could upload a file with a name that ended in almost any string we
wanted, and this string would become part of the command the server
executed. By formatting the string in a particular way, we could cause the
server to execute commands on our behalf. For example, the filename
ballot.$(sleep 10)pdf would cause the server to pause for ten seconds
(executing the sleep 10 command) before responding. In effect, this
vulnerability allowed us to remotely log in to the server as a privileged

Our demonstration attacks

D.C. launched the public testbed server on Tuesday, September 28. On
Wednesday afternoon, we began to exploit the problem we found to
demonstrate a number of attacks:

  * We collected crucial secret data stored on the server, including
    the database username and password as well as the public key used
    to encrypt the ballots.
  * We modified all the ballots that had already been cast to contain
    write-in votes for candidates we selected
    (Although the system encrypts voted ballots, we simply discarded
    the encrypted files and replaced them with different ones that we
    encrypted using the same key.) We also rigged the system to
    replace future votes in the same way.
  * We installed a back door that let us view any ballots that voters
    cast after our attack. This modification recorded the votes, in
    unencrypted form, together with the names of the voters who cast
    them, violating ballot secrecy.
  * To show that we had control of the server, we left a calling
    card—on the system's confirmation screen, which voters see after
    voting. After 15 seconds, the page plays the University of
    Michigan fight song. Here's a demonstration

Stealthiness wasn't our main objective, and our demonstration had a much
greater footprint inside the system than a real attack would need.
Nevertheless, we did not immediately announce what we had done, because we
wanted to give the administrators an opportunity to exercise their intrusion
detection and recovery processes—an essential part of any online voting
system. Our attack remained active for two business days, until Friday
afternoon, when D.C. officials took down the testbed server after several
testers pointed out the fight song.

Based on this experience and other results from the public tests, the
D.C. Board of Elections and Ethics has announced that they will not
proceed with a live deployment of electronic ballot return at this time,
though they plan to continue to develop the system. Voters will still be
able to download and print ballots to return by mail, which seems a lot
less risky.

D.C. officials brought the testbed server back up today (Tuesday) with the
electronic ballot return mechanism disabled. The public test period will
continue until Friday, October 8.

      What this means for Internet voting

The specific vulnerability that we exploited is simple to fix, but it will
be vastly more difficult to make the system secure. We've found a number of
other problems in the system, and everything we've seen suggests that the
design is /brittle/: one small mistake can completely compromise its
security. I described above how a small error in file-extension handling
left the system open to exploitation. If this particular problem had not
existed, I'm confident that we would have found another way to attack the

None of this will come as a surprise to Internet security experts, who are
familiar with the many kinds of attacks that major web sites suffer from on
a daily basis. It may someday be possible to build a secure method for
submitting ballots over the Internet, but in the meantime, such systems
should be presumed to be vulnerable based on the limitations of today's
security technology.

We plan to write more about the problems we found and their implications
for Internet voting in a forthcoming paper.

Professor J. Alex Halderman <> is a computer
scientist at the University of Michigan./

Freedom to Tinker is hosted by Princeton's Center for Information
Technology Policy <>, a research center that
studies digital technologies in public life. Here you'll find comment
and analysis from the digital frontier, written by the Center's faculty,
students, and friends.

Trust the Vote—not!

Rebecca T Mercuri <>
Mon, 08 Nov 2010 11:02:53 -0500

I was shocked to find on the DCBOEE's website
(<>) that they had decided to proceed
with the use of the voting system they obtained from OSDV to collect
Internet ballots in the 2 Nov 2010 general election, despite it having been
proven to be highly flawed in terms of both security and integrity. I have
become increasingly concerned that the recent wave of "voting hack
exhibitions" are having the reverse effect. I'm not saying that these
experiments shouldn't continue, but by somehow validating that the systems
have been subjected to "testing" (even when this testing exposes massive
vulnerabilities), the vendors and election officials seem to feel that it is
appropriate to go ahead with deployment of these products. "At least we know
[some of] the problems" is no way to run elections.

A lengthy 22 Oct posting by Gregory Miller at the OSDV's TrustTheVote
Project blog (at
underscores this "head in the sand" attitude by lauding the fact that "the
District owns 100% of the source code, which is fully transparent and open
source" as somehow a good thing. Actually this "ownership" means that the DC
Election Officials had the freedom to deploy it, and they apparently did do
so, despite knowing that it was vulnerable to international attack.

Does the DCBOEE really think that their website admonishment about the
paltry $10,000 fine and possible imprisonment is going to stop anyone,
especially foreign hackers (who may not be subject to US laws), from using
proxy servers to avoid detection? Does the OSDV truly believe that the
DCBOEE has the ability to detect tampering if it occurs? And if they
discover that the system was hacked during the actual election, do they have
a plan to allow the affected voters to recast their ballots in a secure way?
Heck, when consumer electronics or automobiles are discovered to have
systemic problems, they are RECALLED! Shouldn't the OSDV folks be ashamed of
themselves for not including a clause in their distribution that IMMEDIATELY
GOVERNMENT ELECTION, if any vulnerabilities test or subsequent data exposes
it as insecure and/or unreliable?

Even more disconcerting is the cavalier attitude by the DCBOEE, in deciding
to go ahead with this moronic experiment, knowing that the system was so
massively flawed. This proves EXACTLY WHAT I (and others, especially PGN)
provide an update to remedy all of the KNOWN problems, there would be no
time to adequately test it, and there would be no way for the voters to
ensure that the CORRECTED version (and not a flawed or hacked one) is being
used at the time of the election.

Open source voting thus provides a false sense of security about electronic
elections, which this sad experience has vividly demonstrated. As Ken
Thompson said in 1984: "You can't trust code that you did not totally
create yourself. No amount of source-level verification or scrutiny will
protect you from using untrusted code."  This is still true, whether the
election community, seemingly well-intentioned developers, and security
experts want to believe it or not. Transparency is NOT equivalent to Trust,
especially in voting systems.

Don't get me wrong, of course I believe that open source is a good thing for
many types of applications—voting (especially over the Internet or in
fully electronic systems) just is NOT one of these. Sure, all aspects of
voting systems must be open to thorough review. But the voting problem
CANNOT BE SOLVED using open source. (If this sounds like a contradiction, it
is, as I described in my doctoral dissertation, downloadable at
<>, because there is an inherent conflict
in the ability to create a trusted system that also provides full
anonymity.) Our election integrity colleagues must ensure that these points
are made whenever they demonstrate vulnerabilities.  Anyone who allows
voters, election officials, and members of the press to think otherwise is
contributing to this outright fraud. Perhaps if the VENDORS are fined
$10,000 and threatened with jail sentences, this charade will finally end.

Voting machines selecting default candidates

Lauren Weinstein <>
Tue, 26 Oct 2010 09:30:09 -0700

Some voters in Las Vegas have noticed that Democratic Senator Harry Reid's
name is checked by default on their electronic voting machines. By way of
explanation, the Clark County Registrar says that when voters choose English
instead of Spanish, Reid's Republican opponent, Sharron Angle, has her name
checked by default.  *Slashdot*, 26 Oct 2010

  [Reid won re-election, perhaps because of the strong Latino vote. PGN]

Data mining Facebook reveals when you're most likely to be dumped

Mark Thorson <>
Wed, 3 Nov 2010 16:41:18 -0700

  [David McCandless plotted occurrences of "break up" and "broken up" from
  10,000 facebook status updates.  The highest peaks were around spring
  breaks (perhaps he counted items such as "I'm spending my break up in the
  mountains?" and "I'm all broken up over my bad grades.") and the first few
  weeks of December.  Beware of Breaks-Bearing gifs.  PGN]

Very interesting that April Fool's day represents a [secondary] peak.
I wonder how many of those were actual break-ups.


Getting Crypto Wrong

Gene Wirchenko <>
Fri, 05 Nov 2010 17:47:43 -0700

Neal Ungerleider, How Haystack Risked Exposing Iranian Dissidents,, 20 Sep 2010

In 2009, Iran was in turmoil, and the Islamic Republic was blocking and
monitoring sites used by opposition groups—until a team led by American
IT specialist Austin Heap built a program, Haystack, and touted it as a
secure and anonymous Web portal for Iranians.  *The Guardian* lauded it, and
U.S. Secretary of State Hillary Clinton personally praised Heap. The U.S.
government even gave him rare permission to export his cryptological
software to Iran. Among an elite group of beta testers—and many more
unauthorized users—Haystack was a godsend.

Then in Sept. 2010, security experts discovered a problem: Iranian
authorities, the very ones Haystack was supposed to circumvent and shield
against, were exploiting massive holes in the encryption scheme to snoop on

  [Beware of anonymity-bearing gifts.  As we have noted here before,
  ALWAYS look a gift (trojan) horse in the mouth.  PGN]

Something has been going right in the fight against spam, viruses, ...

Jonathan Kamens <>
Sat, 02 Oct 2010 23:15:07 -0400

We see a lot of depressing news reported in RISKS, so I thought I'd share
something a bit more upbeat.

I monitor some basic statistics about the impact of spam on my personal
email server. In particular, I capture the number of spam messages that
bogofilter successfully blocks and allows through, and the number of bogus
SMTP connections successfully blocked each day by way of the Spamhaus ZEN
blocklist on my primary and secondary SMTP servers. For those who are
curious, I post graphs of these statistics, updated on a daily basis, at

In the last few months, I've noticed a dramatic decrease in the number of
bogus SMTP connections. Today I finally took a few minutes to run the
numbers. When looking at a 30-day running average, the number of bogus
connections has dropped an astounding 51% since May 14, from 29,184 per day
to 14,287! I've posted a graph showing the decline at

I surmise that some very significant zombie botnets must have been shut down
in the past few months. To whoever is responsible for this: kudos and keep
up the good work!

There has also been a reduction in the spam that gets through the blocklist,
from an average of 168 per day to 132, i.e., a 21% drop.  That's
significant, but not nearly as dramatic as the decrease in blocked SMTP

Rise of VoIP systems open new market for exploitation

Dennis van Dok <>
Mon, 11 Oct 2010 10:15:38 +0200

The trend in telecommunication to replace traditional phone switches with
software-based VoIP systems means that there is a growing market for
scanning the Internet for systems on port 5060, breaking in and re-selling
phone services through them. An unsuspecting company that recently installed
a new VoIP based switch, often with poor default security, suddenly receives
a hefty phone bill for calls to (often expensive) numbers. The perpetrators
make money by offering these services on the cheap, while their costs are
virtually zero.

See the ZDnet article for a rise in abuse in Australia:

There are a number of things to ponder over here:

* The vendors possibly ship these systems with a default password, or
  allow anonymous VoIP registration, so it works 'out of the box'.

* The people who install these systems may be coming from a different
  branch than the system administrators who have had to deal with
  protecting their servers against the big bad Internet for years.

Banks Rush to Fix Security Flaws in Wireless Apps

Monty Solomon <>
Sun, 7 Nov 2010 10:43:15 -0500

Spencer E. Ante, *Wall Street Journal*, 5 Nov 2010

A number of top financial companies and banks such as Wells Fargo & Co.,
Bank of America Corp. and USAA are rushing out updates to fix security flaws
in wireless banking applications that could allow a computer criminal to
obtain sensitive data like usernames, passwords and financial information.

The central problem is that the apps, which run on Apple Inc.'s iPhone and
Android-based devices from Google Inc., are storing a user's information in
the memory of a cellphone, a basic lapse that the security researcher who
found the flaws said could allow a cybercriminal to access a person's
financial accounts.

The data could be gleaned if a criminal got physical access to the phone. It
could also be obtained remotely if an attacker were able to con a user into
visiting a malicious website, according to Andrew Hoog, chief investigative
officer of viaForensics, a Chicago computer and mobile security firm that
discovered the flaws. ...

U.S. Daylight Saving Time ends with bug in iOS4

Tony Finch <>
Mon, 1 Nov 2010 10:59:52 +0000

The iPhone / iPod Touch OS has a "clock" application that can act as a
stopwatch, countdown timer, multi-timezone world clock, and daily alarm.
(This alarm is distinct from the appointment reminders you can set up with
the calendar app.) I have an alarm set to go off at 07:00 on week days.

On Sunday when the clocks went back, my iPhone's time display correctly
followed the change, and the alarm continued to show the 07:00 setting.
However this morning the alarm went off at 08:00.

(This wasn't actually a problem since our four-year-old son woke us at
about half past six...)

The most expensive SW bug in recorded human history

Henry Baker <>
Sun, 07 Nov 2010 06:45:38 -0800

NPR's Planet Money 5 Nov 2010 details a bug on the U.S. Freddie Mac website
which refuses to accept an "appreciation rate" for housing which is a
negative number.  At some point in the last several years, hundreds of
trillions of dollars (face value) in derivatives were outstanding based on
this same bug, and Ben Bernanke has put the U.S. dollar printing presses
into overdrive trying to get the nominal value of home prices up so that
people will feel richer & start to spend again.  Of course, Ben is p*ssing
into the winds of a category V hurricane, but he deserves a Nobel for

Crowdsourcing videosurveillance

Jeremy Epstein <>
Mon, 1 Nov 2010 11:25:35 -0400

Interesting piece I heard about on NPR On The Media the other day
(  A British company is
setting up closed circuit TVs in stores, and then inviting people to sign up
to watch the cameras in real time (four cameras at a time).  If you see
something bad (i.e., someone shoplifting), you notify the shopowner via
their site.  There's obviously tremendous opportunity for people causing
mischief (i.e., by tagging customers based on appearance), but they seem to
have given consideration to privacy and reliability concerns.

Several interesting things:
- They have a rating system for watchers - if you cause too many false
  alarms, you're kicked out.
- Watchers are unpaid (+), although they can get some rewards.  They
  believe that because people want to reduce crime they'll volunteer
  their time.  Voyeurism, anyone?
- Watchers can't choose what cameras they see, and are assigned stores
  far from where they live (*).
- Shopowners pay about 100 pounds/month for the service (don't know if
  that's for one camera or many).

Lots of opportunities for mischief here (e.g., can the cameras be re-aimed,
will shopowners point the cameras at dressing rooms).  I can't imagine that
it would be interesting for very long, but perhaps if you're really
bored....  After all, this is what minimum wage rent-a-cops do in shopping

This is a great example of the risks of technology (Internet & cameras),
combined with people's wanting to help their communities, tempered with a
healthy dose of voyeurism.

(+) In fact, they *pay* to register!  "Payment of the membership fee
    helps prevent misuse of the system and acts as a barrier to entry to
    stop voyeurism."
(*) Presuming the watcher gives an accurate home address, one presumes.

Student Password Extension

Geoff Kuenning <>
Mon, 01 Nov 2010 18:36:56 +1300

The following was just sent to all faculty and staff at the institution
where I am teaching (some information removed to protect the guilty):

> Student Password Extension
> What will happen
> All students who were created in [...] before 2006 had
> a 6-digit password.  For security reasons, we intend to extend all those
> students' passwords to 8-digits.  After this change is implemented,
> those students with 6-digit passwords will have their passwords extended
> by two letters—qz.  The number of affected students is estimated to be
> 2130.  (Bear in mind this is not the total number of changes, it is just
> the number of students who enrolled this year who have a 6-digit
> password.)
> Notification
> 1.       Affected  students will be emailed about this change;
> 2.       A notice will be put on the Student Campus life page;
> 3.       A notice will be put on the YYY home page;
> 4.       A notice will be put on the computer logon screens;

Geoff Kuenning

The "M" in XML stands for *markup*.  If you don't have anything
outside the angle brackets, you probably shouldn't be using XML.

Risks of listening to cries for help

"BROWN Nick" <>
Sat, 30 Oct 2010 21:49:05 +0200

The BBC web site reports (
that a UK company has "produced software which it said can analyse the
pitch, tone and intonation of noises [captured by public CCTV cameras] and
work out if they pose a threat".

A company spokesman commented: "A certain number of false positives are
beneficial so long as you have the security bandwidth to cope with them
because you'd rather know about things that you think were an incident than
just miss things you failed to be alerted to."

It's not made clear in the article whether the firm in question is familiar
with Bayes' theorem, or has considered the risk of false positives in
jurisdictions where an armed response is likely (or false negatives, in
cases where people are being assaulted but calling for help in the wrong
tone of voice).

Remote starter risk

Sun, 7 Nov 2010 20:33:10 -0500

A woman died and and her husband was hospitalized after someone in the house
accidentally pressed the "remote-start" button for her car in their garage
in Raleigh VA.

Cellphone's Missing Dot Kills Two People, Puts Three More in Jail

Gene Wirchenko <>
Wed, 03 Nov 2010 12:54:32 -0700

The life of 20-year-old Emine, and her 24-year-old husband Ramazan Calcoban
[with a Turkish equivalent of a cedilla under each c] was pretty much the
normal life of any couple in a separation process. After deciding to split
up, the two kept having bitter arguments over the cellphone, sending text
messages to each other until one day Ramazan wrote [or at least intended to
write] "you change the topic every time you run out of arguments."  The lack
of a single dot over a letter [i]—product of a faulty localization of the
cellphone's typing system --caused a chain of events that ended in a violent
blood bath. (Warning: offensive language ahead.)

The opening picture and caption is horridly insensitive as well.  It is a
fixed image.

  [The confusion resulted from the absence of a Turkish character (the
  "closed i"), which is missing in many Turkish cell phones.  The exact
  misinterpretation was dramatic, and is noted in the cited article.  It
  clearly resulted in serious offense being mistakenly taken by Emine's
  family, and it proved fatal.  PGN]

Texting Stinks?

Gene Wirchenko <>
Fri, 15 Oct 2010 07:27:46 -0700

We all know that walking and texting is a tough combination—but a Staten
Island teen learned the hard way when she fell into an uncovered sewer
manhole while trying to send a message.  Now, the family of Alexa Longueira,
15, intends to sue.  The girl suffered a fright and some scrapes on her arms
back after she dropped into the hole on Victory Boulevard.

Re: Medical Errors (RISKS-26.19)

Thu, 28 Oct 2010 19:18:46 -0600 (MDT)

Surgical "wrong site" errors are an old problem.  Prior to knee surgery 20
years ago a nurse handed me a marker and asked me to draw an X on the spot.
I drew a very large, bold serif X fit for a pirate treasure map.  Just to be
safe, I wrote "no!" all over the other knee.  Most patients choose general
anesthesia but I chose a spinal block.  I will never forget how the surgical
team all laughed when they saw my knees.

And there is this:

Re: Risks of not following standards (RISKS-26.15)

Jerry Leichter <>
Sun, 3 Oct 2010 09:20:36 -0400

Gene Wirchenko forwarded an article from InfoWorld about the problems a Duke
University experiment caused by sending BGP advertisements with a valid but
unrecognized attribute, triggering a bug in Cisco router code that caused a
"partial Internet blackout".

I used to work at a company that did network monitoring software.  We mainly
used SNMP to query devices for their state.  We'd regularly run into bugs in
SNMP implementations.  Some affect only us - e.g., returning ill-formed
packets, or properly-formed packets with garbage data.  But others did
varying degrees of damage, from routers that implemented some queries so
inefficiently that if you made them, the routers would become unusable due
to the resource requirements of trying to answer you, all the way up to
legitimate requests that would cause routers to reset or crash.  In many
cases, when we investigated we'd find that the bugs were known and had long
been fixed by the vendors - but the customer was still running old,
unpatched code.  Some customers would patch; others viewed this as a "it's
working, we're not touching it" situation.  Division of responsibility
between the group that was monitoring the network and the group that "owned"
the devices also factored into this.  The device "owners" blamed our
software for crashing their devices!

We ended up having to avoid some analyses because of the hazards of the
queries they required.

These routers were typically embedded in enterprise networks, not out on
"the greater Internet" - but that's a fluid boundary, since some of them
were internal to providers of Internet interconnect services.  You as a user
couldn't see those devices - but your data flowed through them nonetheless.

There's been little published work on the vulnerabilities of Internet
infrastructure protocols *as actually implemented on real devices*.  I'm
sure there are plenty of vulnerabilities to be found.  BGP, the particular
protocol in question here, is known to have instabilities, and has been
implicated in various accidental (or perhaps not?)  misconfigurations that
have caused wide-spread, problems in recent years.

The mentioned article ends with the scary quote: "The days of academics
playing with a live network are kind of gone now...."  This is a recipe for
stagnation - and for hiding, not fixing, significant problems.

Please report problems with the web pages to the maintainer