Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[R0b0t1]

On Fri, Dec 16, 2016 at 1:16 PM, Rich Freeman <rich0@g.o> wrote:
> On Fri, Dec 16, 2016 at 11:51 AM, Miroslav Rovis
> <miro.rovis@××××××××××××××.hr> wrote:
>> On 161216-08:35-0500, Rich Freeman wrote:
>>>
>>> I'm not sure I understand what distinction you're making.  I can't say
>>> I'm intimately familiar with the security model around Pulseaudio (at
>>> a glance it seems similar to X11 with its use of cookies, though
>>> obviously if you tell it to broadcast unencrypted multicast RTP on
>>> your LAN you'll get the obvious effects) but X11 has a couple of
>>> glaring security weaknesses.  The most obvious is the fact that any
>>> random X11 client can read the keyboard input of any other client on
>>> the same server unless you jump through a bunch of hoops that I don't
>>> think anybody actually jumps through (though I do believe some of the
>>> X11 PIN entry programs may use them at least).  Anything you type into
>>> an xterm could be read by your browser, and in turn by any code able
>>> to execute outside any sandbox that browser might have (root privs not
>>> needed for this).
>>
>> I don't claim it can not, but I doubt anyone can do it in my
>> grsecurity-hardened based Gentoo machine.
>
> As far as I'm aware grsecurity provides no protection against X11
> client evesdropping.  This is an X11 "feature" and not an exploit
> per-se.
>
> Here is one overview of the possibilities:
> https://pipefish.me/2012/08/28/spying-on-screens-and-keystrokes-the-dangers-of-open-x11/
>
> Any program that has access to your X11 cookie and which can connect
> to your X server (which includes anything actually displaying a window
> on your screen), can generally grab any of the keyboard input bound
> for any window on your screen.  There are ways for programs to block
> this, but they're not super-practical.
>
> Amusingly enough I stumbled upon this blog:
> https://blog.separateconcerns.com/2014-10-24-cli-passwords.html
>
> This page "helpfully" suggests that you can secure your system by
> using a console pinentry program instead of an X11-based one, with the
> underlying assumption being that console software is more secure for
> this sort of thing.  While the basic assumption is probably true, in
> this particular case it is definitely not.  Entering a password on an
> actual virtual console or over ssh is in fact secure.  However,
> entering it into an xterm (which is presumably what you're using if
> you would otherwise be using an x11 pinentry program) is absolutely
> not secure.  The x11 pinentry program probably uses XGrabKeyboard to
> ensure that other clients can't evesdrop, while the console-based
> version doesn't know anything about x11.  Some xterm implementations
> have a secure mode buried in the menus which turns on this mode which
> you can use to safely enter passwords, but almost nobody knows about
> this.
>
> There are a lot of "cargo cult" tips out there which are based on a
> lack of understanding of how software like X11 actually work.  Of
> course, X11 is so convoluted that almost nobody actually understands
> everything about how it works, which is why Wayland has always been
> right around the corner.  In general, though, it largely dates back to
> an era where people had rsh listening on all their hosts.
>
>>
>>> And I wouldn't be surprised if a lot of X servers still run as root
>>> for modesetting/etc.
>>
>> What user is that? It you want, tell me how to check it, and let's see
>> how spyware-prone my system is.
>
> If you don't have USE=-suid on your xorg-server package, then X is
> probably running suid root.
>
> In order to not have it run this way you need support for kernel
> modesetting.  I was surprised when I found out that X11 even worked
> that way (we're talking late 90s here).  It seems a bit like running
> pppd as root so that it can directly talk to a UART because you have
> an aversion to using /dev/ttyS*.  In any case the kernel devs have
> generally been making the move to kernel modesetting so that your
> device drivers actually are in the kernel and not in random userspace
> programs (I'm all for microkernels, but not like this).
>
> If you don't have kernel modesetting enabled then X11 won't be able to
> run with -suid set.  Google for gentoo kernel modesetting for a guide
> on how to enable it on most modern hardware.
>
>>
>> It's been discussed over and over again. Lots of people are firm in
>> their understanding that Lennart is an actor by and for the big
>> business. Me too.
>
> Well, he is a Red Hat employee.  Nobody really debates that.
>
>>
>> Whatever would anybody try to claim Pulseaudio code is, but to make up
>> for what was missing in some FOSS GNU Linux boxen for the missing
>> functionality that the big players couldn't otherwise get for their
>> Total Surveillance...
>>
>
> Uh, if the NSA wanted to spy on your box I doubt they'd do it by
> trying to sneak something into the open-source pulseaudio code that
> has numerous maintainers and which is copied all over the place.

There is at least one example of patches that, when taken together,
introduce a bug into code. A particularly insidious example is
described here:
https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/
(no endorsement of the parent site implied).

And there are more mundane examples involving attempting to modify the
repository: https://lwn.net/Articles/57137/. This methodology is used
as there is greater ROI in subverting infrastructure. It's easier to
introduce mistakes than to find honest ones.

> They'd probably just load some microcode into your audio hardware, and
> have it talk to some microcode in your NIC hardware, and if they
> needed some buffer they'd work it into your hard drive firmware.  Then
> it works no matter what OS you're using at the moment, or even if you
> boot off of a DVD.

These types of exploits are reserved for military use against state
actors as a last resort. The thinking is withholding the complex, hard
to find - but also hard to create and emplace - exploits keeps them
relevant in case they are needed in the future.

Generally what is attempted first is compromise of communication
infrastructure, e.g. hacking your home router. They are easy targets
(intentionally; even secure users often don't realize their router's
firmware authenticity is not easily verifiable) and provide a point
from which to launch further attacks on your personal computer or
devices inside the network.

Anecdote: Friend of a friend's roomate was in the process of being
radicalized(?) and their router was hacked by the FBI.

> And if they did want to do it more traditionally in userspace, they'd
> hardly be foiled because you aren't running Pulseaudio.  They'd just
> modify your ALSA drivers or run a program that simply opens your
> microphone and sends the audio to some remote host.

I'd be worried about Intel AMT, the AMD variant, and the ARM variants,
which carry with them the implication that every computer since ~2008
can not be secured. Applying this reasoning to computer peripherals
concludes much the same thing. I suspect the prevalence of
phone-processor-based SBCs is in part due to the Chinese military
trying to obtain verifiably secure computing infrastructure.

Of course, all of this is offtopic.