Bug #12315

Mitigate CVE-2017-2636 (LPE)

Added by cypherpunks 5 months ago. Updated 3 months ago.

Status:ResolvedStart date:03/09/2017
Priority:HighDue date:
Assignee:-% Done:

100%

Category:-
Target version:Tails_2.12
QA Check:Pass Blueprint:
Feature Branch:bugfix/12315-CVE-2017-2636 Easy:
Type of work:Code Affected tool:

Description

Since Tails has CONFIG_N_HDLC=m in its kernel config, it is vulnerable to CVE-2017-2636. Calling TIOCSETD against a pseudoterminal will autoload the vulnerable module, allowing any user to escalate their privileges. See: https://security-tracker.debian.org/tracker/CVE-2017-2636

A mitigation is to blacklist n_hdlc in an /etc/modprobe.d/ entry.

Bug details:

N_HDLC line discipline uses a self-made singly linked lists for data
buffers and has n_hdlc.tbuf pointer for buffer retransmitting after
an error. If sending of a data buffer is not successful, then its
address is saved in n_hdlc.tbuf and the next time n_hdlc_send_frames()
will try to resend it first of all.

But the commit be10eb7589337e5defbe214dae038a53dd21add8 ("tty: n_hdlc add
buffer flushing") introduced racy access to n_hdlc.tbuf.

After transmission error concurrent flush_tx_queue() and n_hdlc_send_frames()
can put a buffer pointed by n_hdlc.tbuf to tx_free_buf_list twice. That
causes an exploitable double free error in n_hdlc_release().

To fix the issue I used a standard kernel linked list protected by a spinlock
and got rid of n_hdlc.tbuf. In case of transmission error the current data
buffer is put after the head of tx_buf_list.

Associated revisions

Revision 9346d02b
Added by intrigeri 4 months ago

Protect against CVE-2017-2636 by disabling the n-hdlc kernel module (refs: #12315).

Revision 076adc6e
Added by intrigeri 4 months ago

Merge branch 'bugfix/12315-CVE-2017-2636' into feature/stretch (refs: #12315).

Revision a494dca8
Added by anonym 4 months ago

Merge remote-tracking branch 'origin/bugfix/12315-CVE-2017-2636' into stable

Fix-committed: #12315

History

#1 Updated by intrigeri 5 months ago

  • Status changed from New to Confirmed
  • Assignee set to anonym
  • Priority changed from Urgent to High
  • Target version set to Tails_2.12

A mitigation is to blacklist n_hdlc in an /etc/modprobe.d/ entry.

anonym, can you take care of this?

#2 Updated by cypherpunks 5 months ago

This might be a useful way to what profiles are able to access the pseudoterminal. It's not perfect because it only looks at one, and it doesn't check for write permission for the character device. I don't have a Tails system handy right now, but manual analysis makes it look like Tor Browser cannot access the pseudoterminals.

cat /sys/kernel/security/apparmor/policy/profile/*/name 2>/dev/null | while read -r i; do
    if aa-exec -p "$i" -- stty -a < /dev/pts/0 >/dev/null; then
        echo "$i" 
    fi
done

Is resolving this bug going to take until the next version of Tails, or is an emergency release going to be issued for this quite severe vulnerability?

#3 Updated by intrigeri 4 months ago

I want it to be fixed in 3.0~beta3 (today).

#4 Updated by intrigeri 4 months ago

  • Assignee changed from anonym to intrigeri

… so I'll take it.

#5 Updated by intrigeri 4 months ago

cypherpunks wrote:

Is resolving this bug going to take until the next version of Tails,

Yes: 2.12 and 3.0~beta3.

or is an emergency release going to be issued for this quite severe vulnerability?

We can't afford doing emergency releases for every local priv esc :/ … yet. (Reproducible builds will make this a bit cheaper.)

#6 Updated by intrigeri 4 months ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from intrigeri to anonym
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/12315-CVE-2017-2636

#7 Updated by cypherpunks 4 months ago

intrigeri wrote:

cypherpunks wrote:

or is an emergency release going to be issued for this quite severe vulnerability?

We can't afford doing emergency releases for every local priv esc :/ … yet. (Reproducible builds will make this a bit cheaper.)

I hope that at least the upgrade importance will be rated as high, instead of medium as it is every other time.

#8 Updated by intrigeri 4 months ago

I hope that at least the upgrade importance will be rated as high, instead of medium as it is every other time.

What's the "upgrade importance"?

#9 Updated by cypherpunks 4 months ago

intrigeri wrote:

I hope that at least the upgrade importance will be rated as high, instead of medium as it is every other time.

What's the "upgrade importance"?

Urgency, I mean. For example, from the changelogs:

tails (3.0~beta3) unstable; urgency=medium

#10 Updated by intrigeri 4 months ago

Urgency, I mean. For example, from the changelogs:

> tails (3.0~beta3) unstable; urgency=medium
> 

I see. Thankfully we don't communicate this to users as "upgrade importance".

#11 Updated by cypherpunks 4 months ago

intrigeri wrote:

Urgency, I mean. For example, from the changelogs:

[...]

I see. Thankfully we don't communicate this to users as "upgrade importance".

This has confused me and others I have talked to in the past, then, considering users are linked to the changelog. Perhaps it should be clarified or removed in that case, but that's for another ticket.

#12 Updated by anonym 4 months ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

#13 Updated by anonym 3 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF