Bug #8571

MAC spoofing failure doesn't result in panic mode (module removal)

Added by anonym 2015-01-06 17:22:10 . Updated 2015-01-15 03:50:22 .

Status:
Resolved
Priority:
High
Assignee:
Category:
Spoof MAC
Target version:
Tails_1.2.3
Start date:
2015-01-06
Due date:
% Done:

100%

Feature Branch:
bugfix/8571-fix-mac-spoof-panic-mode
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

If MAC spoofing fails, we have specified that we’re supposed to enter into a panic mode were we do our best to prevent the device in question to talk to the network (and hence leak the real MAC address) by removing the module etc. However, if macchanger returns an error we will actually not do this. See this extract from config/chroot_local-includes/usr/local/sbin/tails-spoof-mac:

spoof_mac() {
    local msg
    if ! msg=$(macchanger -e "${1}" 2>&1); then
        log "macchanger failed for NIC ${1}, returned ${?} and said: ${msg}"
        exit 1
    fi
}

The problem in the above is exit 1, which prevents the panic mode code from ever running. What was actually intended was probably return 1, which indeed will fix this issue. However, let’s first look at the context in which spoof_mac() is called:

for i in 1 2 3; do
    spoof_mac "${NIC}" || :
    NEW_MAC="$(get_current_mac_of_nic "${NIC}")"
    if [ "${OLD_MAC}" != "${NEW_MAC}" ]; then
        break
    fi
done

So, we ignore any failure status returned from spoof_mac(). We actually probably want to immediately enter the panic mode if macchanger fails, for added fail-safeness.

Subtasks

Related issues

Related to Tails - Bug #8685: Adapt waiting for user notification facilities for Jessie Resolved 2015-01-13
Related to Tails - Bug #9531: MAC spoofing failure doesn't result in panic mode (module removal), bis Resolved 2015-06-04

History

#1 Updated by anonym 2015-01-06 17:34:58

  • Status changed from Confirmed to In Progress
  • Assignee deleted (anonym)
  • % Done changed from 0 to 50
  • QA Check changed from Dev Needed to Ready for QA
  • Feature Branch set to bugfix/8571-fix-mac-spoof-panic-mode

anonym wrote:
> The problem in the above is exit 1, which prevents the panic mode code from ever running. What was actually intended was probably return 1, which indeed will fix this issue.

Commit 3b6f94e.

> We actually probably want to immediately enter the panic mode if macchanger fails, for added fail-safeness.

Commit 54a80db. I really think this makes sense, as I explain in the commit message.

#2 Updated by intrigeri 2015-01-07 10:39:24

  • Assignee set to anonym
  • QA Check changed from Ready for QA to Info Needed

anonym, any suggestion wrt. how to test this?

#3 Updated by anonym 2015-01-13 12:55:53

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Info Needed to Ready for QA

intrigeri wrote:
> anonym, any suggestion wrt. how to test this?

This automated test WIP found in the branch test/xxx-macchanger should give you an idea.

Also, note that I’ve pushed commit 8156352, which should be tested like the ‘see the “Network card disabled” notification’ steps, or via the instructions posted in the thread on tails-dev@: https://mailman.boum.org/pipermail/tails-dev/2015-January/007825.html

#4 Updated by intrigeri 2015-01-13 13:23:44

  • related to Bug #8685: Adapt waiting for user notification facilities for Jessie added

#5 Updated by Tails 2015-01-13 14:41:44

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:370dbd4b6a5260e048b19e6bf290c09c689943c0.

#6 Updated by intrigeri 2015-01-13 16:19:29

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#7 Updated by BitingBird 2015-01-15 03:50:22

  • Status changed from Fix committed to Resolved

#8 Updated by intrigeri 2015-07-08 11:53:50

  • related to Bug #9531: MAC spoofing failure doesn't result in panic mode (module removal), bis added