Yes, really, I did (predict IME security bugs)

I usually try to resist the temptation to say "I told them so".  Saying "I told you so" doesn't make you popular with the people you told.  It is better to move forward and get things done, with the cooperation of those people, than it is to be proven right but shunned.

But in th case of the Intel IME / IAMT / ARC embedded CPU inside the master CPU/chipset, I am going to give in.  Because, yes, really, I did predict such security bugs. 

Darn...  I wrote a moderately long diatribe.  But loxt it because "Blogger is not a content management system, and does not proviode veersioning."  (I could swear blogger used to version - perhaps I am misremembering Google docs.)

Briefly:

Many folks believe that an "assistant" embedded processor is the answer to every problem in computer architecture: I/O; DMA; block memory copies; ... manageability; security.

Problem: 

The "assistant" embedded processor often has a less evolved security architecture than the "master" CPU.  Processor hardware, OS, SW.   Often the reason that the assistant embedded processor is more efficient is that it has thrown out advanced security. E.g. virtual memory page protection. E.g. privilege levels.

Oftentimes, the people advocating such "assistant" embedded processors say "It doesn't matter, we are only using it in narrowly constrained ways.  We can prove the code secure."  Yeah, right.

Over time, such "assistant" processors have added more and more security features.

But even when the assistant embedded processor has security features comparable to the master CPU, it still sucks that it is different.

By construction there will be more code in such a system to code review and security audit.  Even if functional code is the same, there is boot code.

Worse, the assistant and master may have comparable but slightly different security models.  E.g. one may have page permissions RWX-RW-RX but not execute only or read-only, the other may have all the relevat permissions RWX-RW-RX-R-X. Just a small difference, but it can matter.

Worse yet, there is a limited supply of experts for code reviews and security audits.  Even for one system, typically the master.   Even more so if they must be expert in both master and assistant processors.  Moreover, even if you can find such experts, it is damned hard to keep both of them in your head at the same time. It is common to say "oh, that's okay on x86 but not on ARC (or MIPS, or ARM, or your favorite embedded processors)", and later realize that you have it wrong.  Or vice versa.

Worse yet if simuilar but slightly different OSes and SW librraies are available on master and assistant.

Why heterogenous, given risks?

Given the security risks of heterogenous systems with different master and assistant processors, why do them?

Apart from the "my embedded processor is inherently more efficient than your master CPU" wars - which are usually wrong, although possibly true in certain instances (certainly for specialized I/O processors such as GPUs and DSPs) - the biggest reason to have embedded processors separate from the master CPU is:

OS independence.

If the embedded processor provides a high-enough-level API that it can be used without substantial modification for many different OS clients, then you may have less code to maintain (and code review, and security audit).

Furthermore, the very functions that you wish to provide using the assistant embedded processor may need to be protected from the OS.  E.g scanning for malware.

Plus, in a minor way, the fact that the assistant embedded processor is running a different ISA than the mass-market main x86 CPU makes it a little bit les likely that Joe Random Cracker has the skillz to break in.  But I would not count on that.  (Besides, you can get ISA encoding diversity whike preserving ISA semantic consistency. See below.)

Mitigations:

Dedicate parts of Multiprocessors: I like the way that IBM mainframes do manageability: in an LPAR, typically one of the mainframe CPUs is reserved to run the manageability tasks.  Same CPU architecture.  Sometimes even the same OS architecture, although running with hypervisor (MVME) privilege.

You could have different microarchitectures with same ISA and privilege architecture.   But many companies cannot afford to create such a diversity of microarchitectures, while customers may want to license only one instance of the popular but most expensive. (IMHO licensing should encourage such consistent, rather than discourage.)

Shared memory is a security hole:   We live in a world of web services, SAAS (Software As A Service) - get used to it. If the heterogenous "assistants" in your SOC interface via message passing, or even as if over a local TCP/IP network (hopefully a high performance, NATed, local network) - well, at least you are in the range of things that we should know how to secure.  Even though we often fail.

Trouble is, this only works for services that can be decoupled via message passing.  It doesn't work for a service that requires access by the assistant embedded processor to master CPU memory, e.g. for virus scans of active DRAM, or for DRAM deduplication.  But it can work well enough for things like virus scanning of data as it flows from NIC to ME to CPU. If it flowed that way...

Message passing not fast enough?  We know how to make it faster.  Zero copy tricks.   Direct modification of master CPU page tables.   Hardware TLB shootdown mechanisms.  Easier when all parties have similar virtual memory architecture.
      Trouble is, most modern CPUs can only vaguely hope to accelerate message passing interfaces - via a "Smart" embedded assistant processor.
      In some ways I advocate standardizing message passing, possibly using risky shared memory tricks - so as to reduice the need to use such shared memory tricks to interface to other "Smart" devices.

Even higher performance message passing directly accessing processor registers.   But that is even harder to do heterogenously, although I can imagine APIs.

But...  the infamous Intel AMT bug occurred because the "smart" embedded processor was running a poorly secured webserver.  Yep... there's no helping it.   Although we should know how to secure a webserver, we keep f**king up.
      But...  a bug in an SOC embedded webserver woud not have been so bad if isolated to a subsystem that could only access 1 NIC in a multi-NIC system. It is the fact that the subsystem that was compromised has such global access, to everything, more than an OS or hypervisor - that is the really bad thing.

IMHO the Principle of Least Privilege is not just a good idea - it should be the law.  As in, if a company designs a system with blatant disregard for the PLP, and if somebody sustains losses as a result of a security compromise, then they should be liable. And more.
     All of these mitigations are really just ways of saying "Principle of Least Privilege".
 
If you have to allow the "smart" assistant processors shared memory access to master CPU memory: Hardware level firewalls. Standard control and status register space and enumeration, so that you can verify that they are correctly configured.   Unchangeable hardware IDs as well as software IDs on bus transactions, so that you can easily create invariants like "the network packet filter is never allowed to directly access the audio microphones".  (Of course, you might want to allow the NIC to access the microphones for ultra-low-power voice conferencing. And the packet filter, for NSA-like stuff.)

Hardware Page Protection Keys:  associated with physical addresses, or at least the addresses seen on the bus. In addition to virtual address based protection.

Memory Encryption:  may not prevent access by malware running on an embedded processor to CPU storage, or vice versa.  But may prevent secrets leaking, and prevent malware crafting attack packets, whether code or data, to compromise further.\

I suppose that I should also mention capability systems for privilege management, both OS/SW, but possibly also hardware to shared memory. Fine grain.   But I butted my head against that wall, most recently with what became Intel MPX.

Conclusion

"Smart" assistant embedded processors have security risks.  

We really want to prevent "smart" assistant embedded processors from being "smart-ass".  Or, worse, "evil genius".

Intel IAMT bug: strncmp(trusted,untrusted,strlen(untrusted))

Intel's embarrassingly negligent IAMT bug seems ... easy to imagine how it happened.

Embedi's analysis shows that the bug is in code that looks like

if( strncmp(computed_response, user_response, response_length) )
    exit(0x99); 

using the user_response length to limit the length of the string comparison, rather than the expected length (which I believe is, in this case, constant 16, 128-bits, the length of the MD5 hash used in Kerberos authentication).

Immediately I thought of

strncmp(computed_response, user_response, strlen(user_response))

which inspired the riff below

Pay no attention to the riff below

Embedi's writeup indicates that the user_response is actually

struct AUTH_HEAD_VALUE {
    char *str;
    int len;
};

which probably invalidates any supposition that strlen may have one time been involved.

Nevertheless, the riff is fun, and although inaccurate in detail, probably has some aspects of truth.

Riffing on strcmp(trusted,untrusted,bad_length)

When I heard and saw

strncmp(computed_response, user_response, response_length)

Immediately I thought

strncmp(computed_response,
    user_response, strlen(user_response))

I imagined the original code was

strcmp(computed_response, user_response)

I guessed that some "security audit" might have said

Security Auditor: strcmp is insecure, this code must be changed to use strncmp

Might not have been a human security audit.  Might have been a secure-lint tool.

---

The programmer who made the change to use strncmp looked around for a size_t to use as the maximum length to compare.  If the strings were "naked" null terminated C strings, he may just have guessed wrong, choosing the second rather than the first.

 Embedi's writeup indicates that the user_response is not a naked C string, but is actually

struct AUTH_HEAD_VALUE {
    char *str;
    int len;
};

Hey, wait, there's a length here we can pass to strncmp!  It just happens to be the user response length. The wrong string length.

---

Perhaps it was not obvious (to the programmer making the change) what the buffer length of the computed_response is.  BTW, it is really a buffer length, not a string length.  It might be declared as

typedef uint32_t MD5_hash[MD5_SIZE_IN_WORDS]

or

typedef MD5_hash[MD5_SIZE_IN_BYTES]

Or it might have been malloc'ed.

The code might have made some provision for changing eventually to a non-MD5 hash, so you would not want to hard-wire the MD5_SIZE into the code. The code doing the comparison might not need to be aware that the hash involved was MD5.

---

Possibly the hypothetical strcmp code was actually more secure than the strncmp code - so long as both hashes were guaranteed to be null terminated.  So long as the user response was guaranteed not to overflow any buffer allocated for it.

---

But come to think of it, optimized network code probably does not copy the user response from the header into a separate newly allocated string.  It probably sets AUTH_HEAD_VALUE.str to point directly into the buffer containing the headers.

(Or at least the buffer containing part of the headers.  If the headers are split into several buffers... well, that's a bug that has been seen before.)

So, it is probably not "naked null-terminated C string" data.  Probably not:

strcmp(computed_response, user_response)

But if it were, then

strncmp(computed_response, user_response,
            max(strlen(computed_response),strlen(user_response)) )

might have been better.  Really that is equivalent to strcmp - but at least it might silence the security audit tool's warning about strcmp. Replacing it by equally annoying warnings about strlen instead of strnlen.

---

But - the code audit / lint tools that might have triggered this may not have been security oriented. They may have been using a buffer overflow detector like valgrind or purify. These may have warned about read accesses beyond the memory allocated to hold the hashes.

Strictly speaking, neither strcmp not strlen need to perform buffer overflow read memory accesses, if given properly sized null terminated C string arguments.  But... if an "optimized" strcmp or strlen is used, it is common to process things 4 or 8 bytes at a time - the number of bytes that fit into a 32-bit or 64-bit register - in which case the code might read beyond the end of the memoryu allocated for the string, past the terminating null byte.  In past lives, when I was more the "low level assembly code optimization guy" rather than a security guy, I have written such code.  It is hard to write optimized strcmp and strlen code that doesn't go past the terminating null, that still runs faster than doing it a byte at a time. Even fixed length strnlen, strncmp, bcopy, memcpy are hard to write using registers wider than the official granule size, without going past the end.  Which is one reason why I advocate special instruction hardware support, whether RISC or CISCy microcode.

Examining my motivation

When I heard about the IAMT bug, my first reaction was "I told them so - I told them that the ARC embedded CPU would lead to security bugs."  Yes, really, I did (see another post).

But I also said to myself "That's what you get when you have the B-team working on an important feature".

Face it: at Intel, at least when the manageability push started, the A-team worked on CPUs, hardware and software.  The guys working on chipsets and I/O devices were usually understaffed and in a hurry.

I don't like thinking such uncharitable thoughts. Moreover, chipsets and I/O devices are more and more important.  One of the smartest guys I know told me that he decided to go into chipsets because there were too many guys working in Intel CPUs, too much bureaucracy, while in chipsets he could innovate more easily.

So I imagined these scenarios, about code reviews and security audits and lint tools

Security Auditor: strcmp is insecure, this code must be changed to use strncmp

and making changes in a hurry, as a way of imagining how such bugs could have happened.

Doesn't excuse the bugs.  But may be more productive in determining how to prevent such bugs in the future, than simply saying (as I heard one security podcaster say): "This is unimaginably bad code.  One wonders how Intel could ever have allowed such code to pass code reviews and security audits.  One wonders if one should ever trust Intel CPU security again."

Conclusion

My overall point is that code reviews, security audits, and tools such as security lints or buffer overflow detectors, may have triggered code changes that introduced this bug to originally correct code.

This is no excuse.  It is even more important to review code changes than original code, since bug density is higher.

Of course, it is possible that the bug was present since the code was originally written.

'via Blog this'

Problem Gluing Outlook to AutoHotKey – Customer Feedback for Nurgo Software

Problem AquaSnap Gluing Outlook to AutoHotKey – Customer Feedback for Nurgo Software (AquaSnap tiling window manager):

Problem Gluing Outlook to AutoHotKey using AquaSnap

---+ BRIEF

 App windows like Outlook do not have AquaMagnet attraction to my AutoHotKey GUI windows, although the AutoHotKey window is magnetically attracted to Outlook. AquaGlue does not work between these windows.

Q: is this a known problem?

 Q: are there particular settings of the AutoHotKey window that make it visible to AquaSnap?


 ---+ DETAIL

 Not a feature request - more like a problem that I am hoping somebody has already solved.

I just purchased AquaSnap and TidayTabs, with one primary motivation:

I have written an AutoHotKey GUI script that creates an AHK GUI window that contains buttons that are shortcuts for associated applications. E.g. I have on of these AHK "button pads" with shortcuts for Outlook - touch buttons like Archive, file to particular hi/lo priority folders, etc.

I call this AHK-gUIx-SEBP. AHK=AutoHotKey (I have versions in Python, and probably soon in JavaScript). gUIx - Graphical User Interface eXtension. SEBP = Self Editing ButtonPad.

Usually I use this with Outlook on an external monitor, and the AHK buttonpad window on my Surface Book touchscreen. Rather like a MacOS TouchBar, except on steroids, and editable by me, on the fly.

But sometimes I want to use this with both Outlook and the gUIx-SEBP window on the same screen, with no external monitor. In which case I want all of the tliling window manager goodness that something like AquaSnap can provide.

E.g. I want Outlook to occupy most of the screen, with the AHK-gUIx-SEBP in a narrow strip on the right. (Or left. Or top. Or bottom.) Draggable to change the amount of space dedicated to each window.



 Here's the probem that I hope that some AquaSnap user has already figured out:

Resizing my AHK-gUIx-SEBP window gets AquaSnap's magnetically attracted to the Outlook window. But not vice versa - the Outlook window does not get magnetically attracted to the AHK-gUIx-SEBP window. AquaSnap glue does not work. And I cannot grab the edge and have both resized together.

This may well be caused by particular settings of the AutoHotKey window. It does not appear in task bar, but in the notification area. It is optionally AlwaysOnTop, semitransparent for the usual reasons.

I can play around with AHK settings and see if I can make it work with AquaSnap, but I can hope that somebody has already done so, and save me some time."



'via Blog this'

Emacs Fontsets for new Cygwin SurfBook

I recently switched from a MacMook to a Microsoft Surface Book (UNIX/MacOS is nice, but Microsoft is more innovative wrt form factor).



Of course I am still using EMACS.  This go-around using emacs-w32 rather than XWin based emacs.



The default font (fonsets, faces) for emacs-w32 were well-nigh unreadable, at least when scaled up onto large high resolution monitors. Much too thin, too light.

;; Microsoft / emacs-w32
;; w32-standard-fontset-spec
;; "-*-Courier New-normal-r-*-*-13-*-*-*-c-*-fontset-standard"

I first tried bolding everything

(set-face-attribute 'default nil :weight 'bold)

but this lost places where the emacs faces were already using bold to indicate something.

So eventually I figured out how to create new fontsets out of existing fonts on the system

(create-fontset-from-fontset-spec "-outline-Lucida Sans Typewriter-*-*-*-mono-*-*-*-*-*-*-fontset-lucida_sans_typewriter_AGfs")
(create-fontset-from-fontset-spec "-outline-Lucida Console-*-*-*-mono-*-*-*-*-*-*-fontset-lucida_console_AGfs")
(create-fontset-from-fontset-spec "-outline-MS Gothic-*-*-*-mono-*-*-*-*-*-*-fontset-ms_gothic_AGfs")
(create-fontset-from-fontset-spec "-outline-Modern-*-*-*-mono-*-*-*-*-*-*-fontset-modern_AGfs")
(create-fontset-from-fontset-spec "-outline-Consolas-*-*-*-mono-*-*-*-*-*-*-fontset-modern_AGfs")
;; Emacs should support proportional, non-monospace font, but occasionally has problems
(create-fontset-from-fontset-spec "-outline-Arial-*-*-*-*-*-*-*-*-*-*-fontset-Arial_AGfs")
(create-fontset-from-fontset-spec "-outline-Times New Roman-*-*-*-*-*-*-*-*-*-*-fontset-Times_New_Roman_AGfs")
(create-fontset-from-fontset-spec "-outline-Lucida Sans Unicode-normal-normal-normal-sans-*-*-*-*-p-*-fontset-Lucida_Sans_Unicode_AGfs")
;; the create-fontset-from-fontset-spec above apparently create shorthand names
(and nil
  ;; DISABLED - don't load unless needed
  (set-face-font 'default "fontset-lucida_sans_typewriter")
  (set-face-font 'default "Consolas") ; MS font good for programming
  (set-face-font 'default "Courier")
  (set-face-font 'default "Courier New")
  (set-face-font 'default "Lucida Sans Typewriter")
  (set-face-font 'default "Lucida Console")
  (set-face-font 'default "MS Gothic")
  (set-face-font 'default "Arial")
  (set-face-font 'default "Times New Roman")
  (set-face-font 'default "Lucida Sans Unicode")
  )
;; Default font
(set-face-font 'default "Consolas") ; MS font good for programming

With "Consolas" being my new default font.  Oscillating between Consolas and Lucida Console.

TBD: overlap fonts in fontsets to cover the unicode characters that I want to use - French, German, Japanese, Chinese, and math symbols.

I am missing how Apple had better integrated Unicode coverage.

---

See also

EmacsWiki: Font Sets:

Pet Peeve: Cancelling a Meeting via Email but Leaving it in the Shared Calendar (e.g. Outlook or Gmail)

Mark Suster talks about the etiquette of cancelling meetings:

Here’s How to Cancel a Meeting the Right Way – Both Sides of the Table: in advance, with plenty of warning, ideally not the same day or the day before, bearing in mind the possible multiple attendees.

To this I want to add:

Please use the calendar app!

I.e. if the meeting was placed in a shared calendar like Outlook/Exchange or Google Calendar, please cancel it in the shared calendar app.



It sucks when I hurry to a meeting -- where "hurry" may mean finding a quiet room to dial into a teleconference or log into Skype or ... -- and then sit on hold -- because the cancellation message was sent by ordinary email, and the shared calendar app was not updated.  So the event still appears in my calendar.



This sucks because I am often behind in reading email.  Whereas automatic updates to the shared calendar app will be ... automatically updated ... so at the time of the meeting I can see that it is cancelled or not.



I.e. a shared calendar is automatically filtered and classified according to event time.  Email is not.



---



Ideally, a smart assistant like Google Now might be reading your email Inbox, applying natural language recognition to cancellation  messages, and automatically marking the shared calendar event cancelled if a human-written email has recognizably cancelled it.  "Events from Gmail" [1] [2] automatically does this for things like airline flights or hotel reservations, stylized so that it can recognize them.  I haven't yet seen anything smart enough to recognize arbitrary human written cancellations. Plus...  this usually happens with my company Outlook/Exchange calendar, and AFAIK I am not allowed to send all of my company email to Google. Nor am I aware of any Outlook plugin.



---



Companies often use a single shared calendar. (Except for a short time after an acquisition, as IT systems merge.)



When there is no single shared calendar, i.e. when a meeting involves people who use different calendar systems (possibly including paper), you may have to fall back to email.  But even then, many shared calendars send email when a meeting is cancelled, e.g. Outlook may update the Outlook/Exchange shared calendar, and send email to the Google Calendar users.  The stylized form of such automatic emails increases the chance that a smart assistant may be able to recognize it.



---



While I am at it:



Sometimes having a meeting silently disappear from your calendar can be confusing: "I could swear that I had a meeting at 10am..."   In an ideal world, such a cancelled meeting might still show up in your shared calendar application, but be marked as cancelled, grayed out, possibly with an indication as to when it has been rescheduled.



It would be nice if email "conversations" could be attached to a calendar item.



---



Finally:



Many distributed applications are store-and-forward message based, e.g. different calendar instances may be connected by sending email messages back and forth.  As opposed to sharing direct access to a database.



It's not the email message that cancels a meeting that sucks.  It's the lack of automatically updating the calendar item that sucks.



(Email based messaging for distributed applications would be even better if email was secure.)

Personal Blocklist by Google - Google Search

Personal Blocklist by Google - Google Search: "Personal Blocklist Keeps the Sites You Hate Out of Your Google ..."



'via Blog this'





My review:



Good idea, lousy implementation.



Amongst problems: it is far too easy to accidentally block a website - e.g. I just accidentally clicked "Block wikipedia", trying to actually go to wikipedia in search results.



(And wasted time googling "How do I unblock a website in Chrome?", many false leads, until I just reset all of my extensions.)



Typical Google: interesting concept, lousy user-unfriendly UI. Humans occasionally click on the wrong link - there must be a way to repair.



Would be nice to have an extra question "Are you sure you never want to see Wikipedia again in Google search results?"



Would be nice to be able to see list of blocked sites, and edit.



Plus problems such as @EduPimentel mentions, only visually blocking, not replacing with other sites.  (I.e, only filtering, not biasing search.)

Stupid: app != website

FitBit, like many other app/website combinations, does not treat apps and websites equally.



It's not even that the website is a superset of the app. They overlap, but some things can be done on app but not website, and some on website but not app.



Solved: How to add push-ups in exercise - Fitbit Community: "create a custom activity via your website and then log both activities within your app."



'via Blog this'