[conspire] (forw) Re: [Felton LUG] How Democracies Spy on Their Citizens | The New Yorker

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Tue, 26 Apr 2022 12:19:37 -0700
From: Rick Moen <rick at linuxmafia.com>
To: felton-lug at googlegroups.com
Subject: Re: [Felton LUG] How Democracies Spy on Their Citizens | The New
	Yorker
Organization: If you lived here, you'd be $HOME already.

Quoting Robert Lewis (bob.l.lewis at gmail.com):

> https://www.newyorker.com/magazine/2022/04/25/how-democracies-spy-on-their-citizens

As this is a Ronan Farrow piece, it's meticulous.  We could wish that it 
had more about how NSO Group's code exploits work -- how code gets
executed on the target device, and how (if necessary) it escalated
privilege -- but Farrow does cite one example:  NSO's targeting of 
WhatsApp users was via a buffer overflow 'sploit (like countless
other security-impairing bugs).

In another case, Farrow discusses a Pegasus 'sploit against Apple iOS's
instant-messaging app iMessage via a custom-crafted PDF file, which
executed (outside the "BlastDoor" sandbox) the code within the PDF when
iMessage "processed" the PDF.  Ask yourself:  Why on God's green earth
would an instant-messaging program need to parse a PDF just in order to
transmit it between users?  Hold that thought.

What might possibly be a third 'sploit ("Homage") targeted iMessage and
Apple's WebKit[1] HTML engine.  But all of this might be the same attacked
code as the second example.  (Hold that thought, too.)

NSO Group's Pegasus product is a large grab-bag of sundry 'sploits,
continually evolving as their Core Research Group pokes holes in popular
smartphone software, and finds ways to exploit (some of) the found bugs.

Getting to my point:  How is all of this possible?  In my view, key to
what creates the opening is customer demand for excess software
complexity and baroque functionality -- bells and whistles junk, driven
by people and reviewers being wowed by feature lists.

About case #2, I found this technical run-through by Google's Project
Zero:
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html

iMessage had built into it a horrible bit of dumbness:  In figuring out
what to do with files attached to instant messages, it simply believed
that a filename extension of .gif meant it was a GIF image.  This is a
bonehead security error, something worthy of Microsoft.  (See man pages
for file(1) and magic(5) for the traditional Unix way of determining
file types.)  

iMessage tried to spot what attachments are GIF files in order to make
the CoreGraphics API loop their displays endlessly to the user.  So, the
bogus GIF, if I understand this correctly, used this erroneous handling
to evade the BlastDoor sandboxing, and was passed raw to the ImageIO
library, which has code (some of it buggy) to handle over 20 image
formats.  

The Zero Code piece also covers a second dodge that uses phony GIFs to
hit overly complex code in CoreGraphics's PDF parser.  The piece's
explanation is very long, and I'm not going to try to paraphrase it;
see the piece, if interested.


Anyway, angling back to my point:  Some coder took an inexcusably
airheaded approach to the security problems inherent in handling public
data off the Internet, and also threw software complexity around like a
metaphorical drunken sailor in an obviously dangerous place, just so
smartphone users can send each other animated cat photos and Internet
memes.

You know what I really like, for messaging?  UTF8 text (so I can use all
29 letters of the Norwegian alphabet; don't want to wear the hair shirt
and stick to ASCII, after all).


Here's a companion piece, from _NY Times_, about how firms including the
_second_-nosiest corporation in the world (Google) are spying on users:
https://www.nytimes.com/2022/04/06/technology/online-tracking-privacy.html


[1] WebKit is, in origin, from the Linux/KDE community.  In 1998, Apple
needed a good HTML rendering engine and found it in kHTML, the engine
developed by the KDE Project for the Konqueror Web browser, along with
KJS, Konqueror's Javascript engine, and forked thsoe in 2001 as
WebCore and JavaScriptCore (both under LGPL), which by 2005 were part of
a larger project at Apple called WebKit.  In 2010, a refactoring within
Apple resulted in WebKit2, all of the code still being variously
LGPLv2.1 and 2-clause BSD.


----- End forwarded message -----