
A look at home routers, and a surprising bug in Linux/MIPS - walterbell
https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
======
jstarks
The paper was laborious to read.

The short of it seems to be that Linux used to perform floating point
emulation on MIPS by writing instructions to run to the usermode stack. The
stack therefore had to be executable. This is known to be a bad idea.

A couple of years ago, this code was moved from the stack to a new segment,
but this segment is still writable and executable, and the address is fixed.
This is known to be a bad idea.

And of course the stacks are still executable because the commonly-used
compilers haven’t been updated to request non-executable stacks.

The paper does not propose a solution.

~~~
saagarjha
> The short of it seems to be that Linux used to perform floating point
> emulation on MIPS by writing instructions to run to the usermode stack. The
> stack therefore had to be executable.

Why is this necessary? I see no reason why you can’t emulate floating point
arithmetic in software with no writable and executable segments at all.

~~~
geofft
There's a pretty clear explanation in
[https://lore.kernel.org/patchwork/patch/506101/](https://lore.kernel.org/patchwork/patch/506101/)
:

 _MIPS floating point support requires that any instruction that cannot be
directly executed by the FPU, be emulated by the kernel. Part of this
emulation involves executing non-FPU instructions that fall in the delay slots
of FP branch instructions. Since the beginning of MIPS /Linux time, this has
been done by placing the instructions on the userspace thread stack, and
executing them there, as the instructions must be executed in the MM context
of the thread receiving the emulation._

i.e., the kernel needs to find some place in the userspace process to stick
the emulation code, because the emulation code needs to happen in the context
of the userspace process (e.g., memory access permissions etc.), and ~20 years
ago a convenient place the kernel could write to in the userspace process was
to push things onto the stack and nobody realized that was weird. Historically
the stack was executable everywhere, and when we realized that was a bad idea
because exploits can put shellcode on the stack and stopped doing it on most
architectures, we weren't able to stop on MIPS because of this reason.

If we were rearchitecting this from scratch today I bet there would be
something like a vDSO for this, i.e., the kernel maps a read-only executable
page at a random address when the process starts, and when you try to execute
a floating-point instruction it sets some registers (or pushes data and only
data onto the stack) and updates the instruction pointer to point to that
page. But the simplest fix to the existing architecture was apparently to
specify a non-stack area for the kernel to use, which still involves a W|X
segment, but at least it isn't the stack.

~~~
saagarjha
> If we were rearchitecting this from scratch today I bet there would be
> something like a vDSO for this

This is what I was getting at with my question. There is a way to do this;
sure, branch-delay slots are annoying but they’re not impossible to work
around.

> But the simplest fix to the existing architecture was apparently to specify
> a non-stack area for the kernel to use, which still involves a W|X segment,
> but at least it isn't the stack.

I mean, you protect yourself against trivial buffer overflows, but a good
write primitive is still enough to get code execution. It’s more of a band-aid
than an actual fix.

~~~
geofft
If I'm reading the patch right, you allocate a buffer at a random address and
pass a pointer to the kernel, and then you don't have to hold on to a pointer
to that address any more, right? So unlike with the stack, it should be hard
for an attacker who can only writes to figure out where to write. (Maybe this
isn't true in a 2 GB address space given enough attempts?)

~~~
saagarjha
Yeah, I missed the part where the address is given by the user space thread to
the kernel instead of the other way around. That being said, I’m not sure as
to the amount of entropy the address can have: it might end up being
bruteforceable on 32-bit without having to query the full address space (the
memory region might be a whole page?). The best solution, of course, is to not
have any RWX segments at all.

------
stefan_
I mean, TP-Link could enable all of these basic security features and be
lauded in the paper, then you look 5 minutes and find a "system(<web interface
input>)" level bug in the firmware.

------
ausjke
ASLR, stack protector etc are all enabled in recent openwrt as far as I know,
not sure about DEP though

------
therealmarv
What are the best alternatives? I've read about some open source router
alternatives (both hardware and software) in the past but forget the names.
Also a very good HW with hardened open software could be great. Any
information?

~~~
floil
For myself, I switched everything over to Google WiFi's, precisely because
they auto-update, and having worked previously on a security-focused team at
Google, I trust them to have a competent security team and actually stay on
top of the patches. I don't miss fussing with manually updating router
firmware. Life is too short.

On the other hand, my Nest thermostats were bricked after a software update
this week, so maybe today I'm starting to see a crack in my "auto update is
best" dogma...

~~~
TeMPOraL
> _On the other hand, my Nest thermostats were bricked after a software update
> this week, so maybe today I 'm starting to see a crack in my "auto update is
> best" dogma..._

It works best when the vendor can be trusted to only push security updates and
occasional quality of life improvements. In general, automatic updates tend to
be a vector for bloat, user-hostile features (e.g. spyware), and user-hostile
business practices (e.g. remote bricking).

~~~
Wowfunhappy
Which vendors fit this criteria for you?

I am not aware of _any_ , except—somewhat ironically—for some open source
projects.

~~~
TeMPOraL
> _Which vendors fit this criteria for you?_

None. Hence, personally, I dislike auto updates.

------
renox
Not surprised: I remember that MIPS has instructions to trap on integer
overflow 'for free'(no need to pollute your icache with branch-on-overflow
like other ISA) but compilers don't use these instructions :-( Conclusion: to
a first approximation nobody care about security.

~~~
saagarjha
They don’t use those instructions because unsigned integers in C are supposed
to wrap.

~~~
renox
I was talking about signed integers of course.

------
jhcl
I am not familiar with the services all those routers provide to their
companies but I am not bringing one online without first slapping OpenWRT on
it. Well tested and to my knowledge reliable. Functional for everything I need
it for.

~~~
jlgaddis
I have a small embedded device (that runs OpenBSD) that serves as the router
here at home. It works wonderfully for me and serves my needs well but it
definitely wouldn't be a good choice for 99% of "home router administrators".

Likewise, OpenWRT (and similar open-source router firmware) is a big step up
in quality than probably pretty much anything any router manufacturer ships.

Here's the thing... <rant>

You and I -- and, I'd wager, the overwhelming majority of HN readers -- are
easily capable of replacing our stock firmware, locking it down, keeping it
up-to-date, and so on. Unfortunately, the average person (who likely just buys
one of the cheapest routers they can find on the shelf at Walmart or Best Buy
or similar) isn't.

The average consumer simply doesn't understand that many of these devices they
buy -- especially all of the new "Internet of Things" devices that have been
popping up the last few years -- are completely insecure pieces of trash.
Hell, many of them _don 't even care_ \-- well, until it _directly_ affects
them personally, at least -- so long as "it works". They have no desire to
learn a ton of stuff about computing, networking, or security -- they just
want the ability to monitor what's going on in their house while they're away
or whatever -- and they cannot understand why they should be required to (and
I, personally, don't blame them). They don't know about the whole "convenience
versus security" continuum or just how far away from the "security" side of
that continuum that these devices they're buying to make life more convenient
are.

The average consumer (rightfully) expects that these devices that are
available for them to purchase and install in their homes are (reasonably)
"secure". They simply aren't aware of the sorry state of (in)security in the
software industry.

I think that within the next few years we'll begin to see (in the U.S., at
least) some regulation with regard to security and software. I don't think any
of us really _WANT_ this to happen (it would be much better if the industry
were "self-policing", of course) but it has become apparent that those who are
producing these devices simply aren't going to devote the resources required
to improve the security of their products until they are forced to. </rant>

(Related: for the last seven years (until very recently) I worked for a small
ISP. I was amazed at how very little many of the employees -- including the
ones responsible for all of the networking gear! -- knew or even _cared_ about
security. With the exception of myself (and a recent college graduate who we
hired as, basically, my "junior") nobody even thought about security unless or
until "something happened" that required them to. Having experienced that, it
became clear to me that the average person _REALLY_ isn't gonna give a damn.)

~~~
tormeh
I think part of it is that there's also not that many hackers actually using
exploits. Sure, there are automated stuff like botnets, but there seems to be
little manual hacking done. Chances are, if you have lousy security, you're
still not going to get hacked (unless you're literally holding money, or have
blueprints of military hardware). If this is correct, it means that security
is usually a waste of time.

I really care about security, but I think it's mostly because the aesthetics
of insecure code bothers me, and not because of a carefully considered cost-
benefit analysis.

~~~
posterboy
I rather think the hackers are simply nice, not vandalizing wildly, instead
they stay under the radar and we don't even begin to understand what they
might do with that power (close the holes, I hope).

------
JoshuaJB
Note that this does not effect all MIPS-based systems. The standard has
included hardware floating point for many years now, it just seems some OEMs
have neglected to upgrade or cut it for cost savings.

~~~
floatingatoll
Given the OEMs cited, would it be a reasonable estimation to suggest that the
_majority_ of MIPS-based systems are affected?

~~~
monocasa
Yeah, most consumer routers I've dealt with don't have a FPU. They're more
likely to be dual core than have an FPU.

~~~
snaky
Consumers care about speed and don't care about security, so it's reasonable
choice by vendors.

~~~
saagarjha
Consumers care about security if they’re hacked.

~~~
snaky
They aren't hacked yet when they make decision about buying the router, and
anyway they cannot differentiate based on security promises marketed to them
by vendors.

~~~
saagarjha
> they cannot differentiate based on security promises marketed to them by
> vendors

If $VENDOR has a reputation of being hacked, it might deter people from buying
their products.

~~~
paulie_a
It won't make a difference. Consumers don't care about security on their
devices. That is why I quit frankly like things like Bricker bot. The internet
is an ecosystem and people's devices should be bricked if they are having a
negative effect due to blatant negligence by device manufacturers.

I hope a new round of Bricker bots continue killing devices that are
unsupported, incredibly insecure devices. It is a public service (albeit a
felony, don't get caught)

------
sctb
We've updated the submission from a tweet
([https://mobile.twitter.com/dotMudge/status/10736765802899456...](https://mobile.twitter.com/dotMudge/status/1073676580289945600))
to its linked article.

~~~
lambda
Hmm. The tweet, and thread on Twitter, has more actual information on the
vulnerability than the page you linked to. You have to click through to the
actual paper to get the additional information. I feel like the Twitter link
gives a better quick summary information.

~~~
sctb
I think clicking through to actual papers is something HN is up for!

~~~
lucb1e
Then why not just link the paper?

I personally like the summaries. Papers are typically written to sound smart,
not to read nicely. HTML scales, users can configure the font, you can click
pictures to enlarge... but instead we choose to use PDFs. Why? I speculate it
is because everyone else who sounds smart does it. This particular paper is
not as bad as most (no serif font, 8pt text, small and unreadable diagrams,
references instead of practical links) so it's definitely not all directed at
this particular paper, but I do question the usefulness of linking to a longer
text instead of to a useful summary that has a link to the longer text.

GP is right in that the first 15 words of the tweet told me more than the
whole 269 word blog post. I also recognized the author on Twitter but not on
the blog. I'm happy the tweet is still linked in the comments.

