Monday, 8 January 2018

Toomas Karmo: Our Biggest Cyberproblem Since Y2K: Debian GNU/Linux Observations

Quality assessment:

On the 5-point scale current in Estonia, and surely in nearby nations, and familiar to observers of the academic arrangements of the late, unlamented, Union of Soviet Socialist Republics (applying the easy and lax standards Kmo deploys in his grubby imaginary "Aleksandr Stepanovitsh Popovi nimeline sangarliku raadio instituut" (the "Alexandr Stepanovitch Popov Institute of Heroic Radio") and his  grubby imaginary "Nikolai Ivanovitsh Lobatshevski nimeline sotsalitsliku matemaatika instituut" (the "Nicolai Ivanovich Lobachevsky Institute of Socialist Mathematics") - where, on the lax and easy grading philosophy of the twin Institutes, 1/5 is "epic fail", 2/5 is "failure not so disastrous as to be epic", 3/5 is "mediocre pass", 4/5 is "good", and 5/5 is "excellent"): 4/5. Justification: Kmo had time to develop the necessary points to reasonable length.
Revision history:
All times in these blog "revision histories" are stated in UTC (Universal Coordinated Time/ Temps Universel CoordonĂ©,  a precisification of the old GMT, or "Greenwich Mean Time"), in the ISO-prescribed YYYYMMDDThhmmZ timestamping format. UTC currently leads Toronto civil time by 5 hours and currently lags Tallinn civil time by 2 hours. 


  • 20180125T2152Z/version 3.1.0: Kmo made some very tiny changes in the interest of clarity - changes on the borderline between the substantive and the cosmetic. He reserved the right to make nonsubstantive, purely cosmetic, tweaks over the coming 48 hours, as here-undocumented version 3.1.1, 3.1.2, 3.1.3, ... .
  • 20180123T0530Z/version 3.0.0: Kmo added various points about CERT and about his own choice of security tools. He also corrected a very bad typo (he had said that he was running Debian GNU/Linux 9.2, when in fact he was running 9.3), and corrected minor typos and infelicities. - He reserved the right to make nonsubstantive, purely cosmetic, tweaks over the coming 48 hours, as here-undocumented version 3.0.1, 3.0.2, 3.0.3, ... .
  • 20180109T0325Z/version 2.0.0: Kmo uploaded a fine-grained outline at the top of his page, pushing the coarse-grained outline downward. He hoped to finish converting this fine-grained outline into coherent full-sentences prose at some point in the next 48 hours.
  • 20180108T0037Z/version 1.0.0: Kmo had time to upload just a coarse-grained outline. He hoped to proceed to a fine-grained outline within the coming 2 hours.

[CAUTION: A bug in the blogger server-side software has in some past months shown a propensity to insert inappropriate whitespace at some points in some of my posted essays. If a screen seems to end in empty space, keep scrolling down. The end of the posting is not reached until the usual blogger "Posted by Toomas (Tom) Karmo at" appears. - The blogger software has also shown a propensity, at any rate when coupled with my erstwhile, out-of-date, Web-authoring uploading browser, to generate HTML that gets formatted in different ways on different downloading browsers. Some downloading browsers have sometimes perhaps not correctly read in the entirety of the "Cascading Style Sheets" (CSS) which on all ordinary Web servers control the browser placement of margins, sidebars, and the like. If you suspect CSS problems in your particular browser, be patient: it is probable that while some content has been shoved into some odd place (for instance, down to the bottom of your browser, where it ought to appear in the right-hand margin), all the server content has been pushed down into your browser in some place or other. - Finally, there may be blogger vagaries, outside my control, in font sizing or interlinear spacing or right-margin justification. - Anyone inclined to help with trouble-shooting, or to offer other kinds of technical advice, is welcome to write me via]

The first week in 2018 January brought news of what seems to be the biggest problem in information-technology security since Y2K, comprising the "Meltdown" and "Spectre" vulnerabilities. 


Here are the basics: 

  • Authoritative descriptions of the vulnerabilities are written at the USA's "National Cybersecurity Federally Funded Research and Development Center" (under the non-profit "Mitre Corporation"), as a handful of CVE documents. (CVE is short for "Common Vulnerabilities and Exposures".) Meltdown is covered in CVE-2017-5754. Spectre is covered not in one CVE, but in two: CVE-2017-5753 (to be thought of as reporting Spectre in "Variant 1") and CVE-2017-5715 (to be thought of as reporting Spectre in "Variant 2"). An easy way of checking the USA government's Computer Emergency Readiness Team (CERT) stance on all three CVEs is through the monitoring of ("Vulnerability Note VU#584653", incorporating hyperlinks to appropriate writeups for CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715). It is an advantage that the just-mentioned page gets updated roughly daily (and in fact more often than another pertinent CERT discussion, the less detailed "Alert" at Helpfully, the incorporated hyperlinks lead to documents maintained by the USA's National Institute of Standards and Technology - the same people as we have perhaps come to know, in a way, through their work on spectroscopy standards, or again through their longstanding time-signal (shortwave station WWV) outreach.
  • Of the two, Meltdown is more readily blocked than Spectre.
  • Meltdown is largely, though not completely, confined to Intel CPUs. 
  • Spectre affects not Intel alone, but most or all contemporary CPUs (and so, in particular, affects also Intel's highest-profile competitor, AMD, as well as most or all Intel CPUs from 1995 onward). 
  • The assertion made early in 2018 January at some USA government-agency level, that an effective response to Spectre might require outright CPU replacement, seems no longer to be being made at USA government-agency level, and in particular is being avoided in current writing from CERT. (So perhaps even the deeper of the two vulnerabilities, namely Spectre, can be fully or partly blocked at the level of some thing or things in coding, such as an eventual kernel revision, or more radically an eventual revision in CPU microcode - even while retaining the current, 2017-and-earlier, CPU hardware designs?) 
  • As far as I can see, CERT is silent at the moment on the Google "reptoline" software solution. It might be useful to check reptoline discussions in the general I.T. press over the coming weeks.

I can help with just one thing, as a conceivable future low-level cyber consultant. That one thing is the construction of a humble, single-user Debian GNU/Linux workstation, such as might be appropriate for a classical philologist, a lawyer, a geopolitics analyst, a physicist, or a mathematician. Trying to be helpful, I offer a few notes from my own narrow perspective. Perhaps these notes will serve as a point of comparison for people using GNU/Linux distributions other than Debian, whether for my own narrow purposes or for something in the broad information-technology mainstream (such as sysadmin work on a Web server). 


  • On the same Ontario working day as I noticed the BBC starting coverage of Meltdown and Spectre, Debian rolled out a Meltdown repair, i.e., a repair for CVE-2017-5754 (without, however, repairing either variant of Spectre, i.e., without repairing either CVE-2017-5753 or CVE-2017-5715). 
  • I was advised on that day of the Debian repair by e-mail from Yves-Alexis Perez within the Debian Project, transmitted from at UTC=20170104T2233Z, and received at my a couple of minutes later. 
  • Within an hour of receiving the e-mail alert, I had my Debian 9.3 GNU/Linux "Stable" (codenamed, within the Debian Project, "Stretch") updated, via my usual command uuu (my personally concocted root bash-shell alias for the harder-to-type apt-get update; apt-get dist-upgrade). 
  • In the course of this updating, my system wrote to screen (as was to be hoped) a message saying that I was currently running a kernel older than a kernel now being made available on my system, and that I should therefore reboot. 
  • I encountered no problem in rebooting. 
  • I chose for the moment to keep not one but two old kernels on my system even after the reboot, thereby giving my Debian 9.3 GNU/Linux system the configuration displayed in the following /usr/bin/xterm session:

$ls -l vmlinu*
-rw-r--r-- 1 root root 4204320 Sep 18 21:34 vmlinuz-4.9.0-3-amd64
-rw-r--r-- 1 root root 4212512 Dec 22 19:39 vmlinuz-4.9.0-4-amd64
-rw-r--r-- 1 root root 4216608 Jan  4 06:12 vmlinuz-4.9.0-5-amd64


A subsequent check of currently running processes confirmed that I was indeed, as desired, running the most recent of the three kernels by now sitting on my hard drive:

$date -u
Tue Jan  9 03:24:12 UTC 2018
$cat /proc/version
Linux version 4.9.0-5-amd64 ( (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04)

  • I continue to monitor, occasionally, the situation regarding the still-outstanding vulnerabilities (namely,  CVE-2017-5753, or Spectre in Variant 1, and  CVE-2017-5715, or Spectre in Variant 2). I use for this occasional monitoring and
  • I also find it mildly interesting to run  /usr/bin/debsecan, in addition to my more usual security tools /usr/sbin/chkrootkit, /usr/bin/rkhunter, /usr/bin/clamscan, and /usr/sbin/lynis. (Yes, yes, I know, or at least I kinda-sorta know: there are arguments for installing lynis in some cunning way, perhaps quite outside /usr/sbin, perhaps onto a mere USB stick, and not even doing the install from the behind-the-times Debian "Stretch" repositories. And the pertinent partition on that USB stick might be mounted read-only, with the stick physically detached from the machine when lynis is not being run. I really do have to improve my work here. Maybe my improvements will come very soon indeed, maybe not.) The simple debsecan reveals 1821 CVE notices, issued by Mitre as against myu personal workstation presently comprising 2168 Debian packages, all from Debian GNU/Linux 9.3 (and at the moment not running any software of any kind from outside Debian). Of these CVE notices, fully 118 are from the year 2018. One might expect the generated list to show CVE-2017-5753 and CVE-2017-5715 (Spectre and Spectre) while omitting a mention of the now-addressed CVE-2017-5754 (Meltdown). Alas, however, all three are in the generated list - at least, on the naive way in which I am so far running debsecan

[This is the end of the current blog posting.]

No comments:

Post a Comment

All comments are moderated. For comment-moderation rules, see initial posting on this blog (2016-04-14).