Re: [Tails-dev] Hacking Team looking at Tails

[Austin English]

Having some hardware issues so I can't build/test this on tails
directly right now, but I put this together as proof of concept on
Fedora.

On Mon, Feb 22, 2016 at 11:31 AM, Spencer  wrote:
> Hi,
>

 Austin English:
 filed https://labs.riseup.net/code/issues/11137

>
> This is a very challenging problem.  There are two cases that come to mind.
>
> 1. The device may become compromised before becoming a Tails device.  In
> this case, the files/partitions are either hidden or protected and are not
> removed during reformatting.
>
> This is best addressed during the creation of a new Tails device.
>
> 2. The device may become compromised after becoming a Tails device.  In this
> case, the files/partitions, which may be hidden or protected, are not
> removed after shutdown.
>
> This is best addressed during either the startup or shutdown processes of a
> living Tails device.
>
>>>
>>> sajolida:
>>> not about detecting malware but about training
>>> users .. good practices
>>>
>
> So, detecting/educating *that* but not *what*.  This seems reasonable, as
> *what* would need blacklists, trust models, and so on.
>
> Also, given the actual (intended/expected) function of the hidden attribute
> files, e.g., preserving user settings, it seems that there are no benefits
> of having these, or any other, files on a Tails device.
>
>>>
>>> Don't plug your Tails in an untrusted OS
>>>
>
> I do not think this is an achievable model to promote because:
>
> - Trust is like STDIN; can be anything to anyone.
>
> - There seem to be no machines or systems that can have the guarantee that
> is referred to when we say 'Trust'.
>
>>>
>>> reinstalling is the only solution .. installing
>>> from the same untrusted OS really won't be.
>>>
>
> And educating (:
>
> How can Tails:
>
> - Inform of this device protection feature and what it does?
>
> - Detect the existence of unwanted files.
>
> - Disclose what the files are and where they were located in the file
> system?
>
> - Provide a resolution to remove the files and restore the devices
> integrity.
>
> - Guarantee the files removed are now gone and will not come back, or
> recommend a behavior model that will limit the possibility of files
> (re)appearing?
>
>>
>> Austin English:
>> help for the ux portion
>>
>
> I would be more than happy to put the files together or think through this
> some more.  Feel free to send anything my way; can be as rough or polished
> as you got it.
>
>>
>> if detected, have the greeter pop up some big red
>> warning box.
>>
>
> This warning could replace the greeter.
>
> This warning might want to be ignored.
>
>>
>> discussed on tails-ux
>>
>
> Copied for migration if needed.
>
> Wordlife,
> Spencer
>
>
>
>
> ___
> Tails-dev mailing list
> Tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to
> tails-dev-unsubscr...@boum.org.



-- 
-Austin


detect_proprietary_garbage.sh
Description: Bourne shell script
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Hacking Team looking at Tails

[Spencer]

Hi,

> 
> intrigeri:
> assuming non malicious storage 
> hardware
> 

The case presumes malicious software and/or hardware, or at least considers the 
uncertainty.

I think most people can, and will, see the storage capacity beforehand.  
However, the firmware takes up space but, to most people, it is unknown exactly 
how much.

> 
> udisks2 creates a new partition table
> 

So, is reformatting re(pre)dundant?


Wordlife,
Spencer



___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[intrigeri]

Spencer wrote (22 Feb 2016 17:31:44 GMT) :
> 1. The device may become compromised before becoming a Tails device.  In this 
> case,
> the files/partitions are either hidden or protected and are not removed
> during reformatting.

FWIW, I'm unsure how applicable this is in practice (assuming non
malicious storage _hardware_): Tails Installer asks udisks2 to create
a new partition table. I don't know what it takes to confuse udisks2
to the point it believes it has succeeded.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Hacking Team looking at Tails

[Spencer]

Hi,



Austin English:
filed https://labs.riseup.net/code/issues/11137



This is a very challenging problem.  There are two cases that come to 
mind.


1. The device may become compromised before becoming a Tails device.  In 
this case, the files/partitions are either hidden or protected and are 
not removed during reformatting.


This is best addressed during the creation of a new Tails device.

2. The device may become compromised after becoming a Tails device.  In 
this case, the files/partitions, which may be hidden or protected, are 
not removed after shutdown.


This is best addressed during either the startup or shutdown processes 
of a living Tails device.




sajolida:
not about detecting malware but about training
users .. good practices



So, detecting/educating *that* but not *what*.  This seems reasonable, 
as *what* would need blacklists, trust models, and so on.


Also, given the actual (intended/expected) function of the hidden 
attribute files, e.g., preserving user settings, it seems that there are 
no benefits of having these, or any other, files on a Tails device.




Don't plug your Tails in an untrusted OS



I do not think this is an achievable model to promote because:

- Trust is like STDIN; can be anything to anyone.

- There seem to be no machines or systems that can have the guarantee 
that is referred to when we say 'Trust'.




reinstalling is the only solution .. installing
from the same untrusted OS really won't be.



And educating (:

How can Tails:

- Inform of this device protection feature and what it does?

- Detect the existence of unwanted files.

- Disclose what the files are and where they were located in the file 
system?


- Provide a resolution to remove the files and restore the devices 
integrity.


- Guarantee the files removed are now gone and will not come back, or 
recommend a behavior model that will limit the possibility of files 
(re)appearing?




Austin English:
help for the ux portion



I would be more than happy to put the files together or think through 
this some more.  Feel free to send anything my way; can be as rough or 
polished as you got it.




if detected, have the greeter pop up some big red
warning box.



This warning could replace the greeter.

This warning might want to be ignored.



discussed on tails-ux



Copied for migration if needed.

Wordlife,
Spencer



___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[Austin English]

On Sat, Feb 20, 2016 at 6:26 AM, sajolida  wrote:
> Austin English:
>> On Thu, Feb 18, 2016 at 11:37 AM, intrigeri  wrote:
>>> Austin English wrote (18 Feb 2016 16:56:29 GMT) :
 I'm not sure what action we should suggest.
>>>
>>> Re-installing from scratch is perhaps the only safe option we can
>>> provide in the current state of our tools.
>>
>> +1
>>
>> I filed https://labs.riseup.net/code/issues/11137 to track this. I'll
>> work on this as time permits. May need some help with the greeter
>> portion, we'll see.
>
> I like this idea. As intrigeri pointed out, this is not so much about
> detecting malware for real, but really about training users about good
> practices "Don't plug your Tails in an untrusted OS". I also agree that
> we should explain that reinstalling is the only solution.
> Though installing from the same untrusted OS really won't be.

Agreed.

> Austin, once you get time to work on the implementation part of this, I
> suggest sharing with us mockups about this would be presented to the
> user on tails...@boum.org before you write the corresponding code (maybe
> you can write the detection code itself first). At least regarding the
> phrasing, when and how the message occurs, what's proposed as ways out
> of the message, the need for extra doc, etc.

Absolutely! I was going to request help for the ux portion, because
I'm uncomfortable with choosing that phrasing, as it is very
important. I'm a native English speaker, but I want to make sure the
message is clear to non-native speakers.

My thought was to have detection code before the greeter, then if
detected, have the greeter pop up some big red warning box. Beyond
that, I'm open to ideas on specifics. But that can be discussed on
tails-ux once the first part is done.

-- 
-Austin
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[sajolida]

Austin English:
> On Thu, Feb 18, 2016 at 11:37 AM, intrigeri  wrote:
>> Austin English wrote (18 Feb 2016 16:56:29 GMT) :
>>> I'm not sure what action we should suggest.
>>
>> Re-installing from scratch is perhaps the only safe option we can
>> provide in the current state of our tools.
> 
> +1
> 
> I filed https://labs.riseup.net/code/issues/11137 to track this. I'll
> work on this as time permits. May need some help with the greeter
> portion, we'll see.

I like this idea. As intrigeri pointed out, this is not so much about
detecting malware for real, but really about training users about good
practices "Don't plug your Tails in an untrusted OS". I also agree that
we should explain that reinstalling is the only solution.
Though installing from the same untrusted OS really won't be.

Austin, once you get time to work on the implementation part of this, I
suggest sharing with us mockups about this would be presented to the
user on tails...@boum.org before you write the corresponding code (maybe
you can write the detection code itself first). At least regarding the
phrasing, when and how the message occurs, what's proposed as ways out
of the message, the need for extra doc, etc.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[Austin English]

On Thu, Feb 18, 2016 at 11:37 AM, intrigeri  wrote:
> Austin English wrote (18 Feb 2016 16:56:29 GMT) :
>> I'm not sure what action we should suggest.
>
> Re-installing from scratch is perhaps the only safe option we can
> provide in the current state of our tools.

+1

I filed https://labs.riseup.net/code/issues/11137 to track this. I'll
work on this as time permits. May need some help with the greeter
portion, we'll see.

-- 
-Austin
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[intrigeri]

Austin English wrote (18 Feb 2016 16:56:29 GMT) :
> I'm not sure what action we should suggest.

Re-installing from scratch is perhaps the only safe option we can
provide in the current state of our tools.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[segfault]

> I'm not sure how the user could detect / verify that
> (realistically, you probably can't..). Running a rootkit checker from
> another *nix OS may be helpful, but of unknown effectiveness.

That's work in progress: https://labs.riseup.net/code/issues/7496
I implemented a prototype that's currently being QA checked:
https://gitlab.com/segfault_/tails_verifier
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[Austin English]

On Thu, Feb 18, 2016 at 10:51 AM, intrigeri  wrote:
>> I was thinking about this last night, it likely wouldn't be too hard
>> to write a wrapper for the greeter to detect if those files (or other
>> similar files/directories, like __MACOSX) are present. It should then
>> be possible to pop up a very big warning in the greeter, ideally
>> before the user has a chance to type in their persistence password (if
>> used) or before starting a session.
>
>> [...]
>
>> Thoughts? If there's interest / lack of opposition I'll file a ticket.
>
> Sounds like this could possibly help educate users about a dangerous
> practice, which seems great! Perhaps the proposal could include a part
> about what action this warning would suggest to the user?

I'm not sure what action we should suggest. Purging those files would
get rid of the warning, but doesn't guarantee that the installation is
safe to use. That may only hide the problem since it may be infected
by an attacker. I'm not sure how the user could detect / verify that
(realistically, you probably can't..). Running a rootkit checker from
another *nix OS may be helpful, but of unknown effectiveness.

> 2 more cts: the exact wording should probably not expose the feature
> as a malware detector (since a Tails system can't verify itself
> reliably, the way it's currently designed).

Agreed.

-- 
-Austin
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[intrigeri]

> I was thinking about this last night, it likely wouldn't be too hard
> to write a wrapper for the greeter to detect if those files (or other
> similar files/directories, like __MACOSX) are present. It should then
> be possible to pop up a very big warning in the greeter, ideally
> before the user has a chance to type in their persistence password (if
> used) or before starting a session.

> [...]

> Thoughts? If there's interest / lack of opposition I'll file a ticket.

Sounds like this could possibly help educate users about a dangerous
practice, which seems great! Perhaps the proposal could include a part
about what action this warning would suggest to the user?

2 more cts: the exact wording should probably not expose the feature
as a malware detector (since a Tails system can't verify itself
reliably, the way it's currently designed).

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[Austin English]

On Feb 16, 2016 2:42 PM, "anonym"  wrote:
>
> Austin English:
> > On Tue, Feb 16, 2016 at 12:25 PM, Spencer 
wrote:
> >>> Austin English:
> >>> write a wrapper for the greeter to detect if those files
> >>> are present.
> >>
> >> It could also detect hidden partitions, correct?
> >
> > Possibly, I'm not sure how that would be accomplished myself..
>
> If you are referring to the "hidden partition" flag, then detection is
> trivial. This flag is just that, a bit somewhere that if set, software
> may *pretend* to not see it, if that has been implemented. :) Yes, a
> piece of software not implementing the hiding would see it, just like
> any other partition.

I'm familiar with that, I'm assuming that could be automated with fdisk or
similar. I didn't know if there was (potentially) something more nefarious
at play.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[Austin English]

On Tue, Feb 16, 2016 at 12:25 PM, Spencer  wrote:
> Hi,
>
>>
>> Austin English:
>> write a wrapper for the greeter to detect if those files
>> are present.
>>
>
> It could also detect hidden partitions, correct?
>
>
> Wordlife,
> Spencer
>
>
>
> ___
> Tails-dev mailing list
> Tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to
> tails-dev-unsubscr...@boum.org.

Possibly, I'm not sure how that would be accomplished myself..

-- 
-Austin
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[Austin English]

On Tue, Feb 16, 2016 at 2:41 AM, Spencer  wrote:
> Hi,
>
>>
>> intrigeri:
>> don't keep a record
>>
>> never looked deeper than the root directory
>>
>
> No worries (:
>
> Wordlife,
> Spencer
>
>
>
>
> ___
> Tails-dev mailing list
> Tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to
> tails-dev-unsubscr...@boum.org.

Those files can definitely end up in lower directories (from what I've
seen of other live usb sticks).

I was thinking about this last night, it likely wouldn't be too hard
to write a wrapper for the greeter to detect if those files (or other
similar files/directories, like __MACOSX) are present. It should then
be possible to pop up a very big warning in the greeter, ideally
before the user has a chance to type in their persistence password (if
used) or before starting a session.

That would also allow differentiating between Windows and OSX, but I
don't think that differentiation matters in practice.

Thoughts? If there's interest / lack of opposition I'll file a ticket.

-- 
-Austin
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Hacking Team looking at Tails

[Spencer]

Hi,



intrigeri:
don't keep a record

never looked deeper than the root directory



No worries (:

Wordlife,
Spencer



___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[intrigeri]

Spencer wrote (12 Feb 2016 02:43:41 GMT) :
> Are these the typical Thumbs.db & .DS_Store files, or are
> there others?

I don't keep a record of them and don't remember, sorry.

> Where are they located, in some/all folders, at top of the package directory, 
> or somewhere outside of Tails?

I never looked deeper than the root directory of the
system filesystem.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Hacking Team looking at Tails

[Spencer]

Hi,

> 
> intrigeri:
> https://labs.riseup.net/code/issues/11102
> 
>> 
>> Snip from the ticket:
>> "Tails USB sticks that have "hidden" 
>> files that indicate they have been 
>> plugged into Windows or OSX 
>> machines"
>> 

Are these the typical Thumbs.db & .DS_Store files, or are there others?

Where are they located, in some/all folders, at top of the package directory, 
or somewhere outside of Tails?

Wordlife,
Spencer


___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[intrigeri]

Hi,

intrigeri wrote (13 Jul 2015 08:24:36 GMT) :
>> o   Infecting USB device which appears to be a bootable disk (Antonio +
>> Giovanni)§ It will drop (release) the scout, then it will run
>> a wipe.

> Seems to be the same, but from a running and already infected
> non-Tails OS, when a Tails USB stick is plugged in it. That's more
> concerning. We should check if we're communicating clearly enough
> that:

>  * the OS used to install or upgrade a Tails device can corrupt it
>  * plugging one's Tails device in an untrusted OS is dangerous

I don't think this has been checked. This thread teaches us that such
targetted attacks against Tails are not theoretical, so I think we
should warn our users against it ⇒ I've created
https://labs.riseup.net/code/issues/11102 so it's tracked somewhat
better than in our inboxes.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[intrigeri]

Hi,

[redirecting this discussion to tails-dev@boum.org, which is more
suitable for this discussion = please drop tor-talk@ from the list of
recipients when replying -- thanks!]

I wrote (12 Jul 2015 13:06:15 GMT) :
 https://wikileaks.org/hackingteam/emails/emailid/25607#efmBTaBTh

 Below research points remain outstanding ... 

 VECTORS · Offline: [...]

 by translate.google.com but obviously not precise but concerning nonetheless.

I got a translation made by a native speaker who's skilled in this
area, quoting it below with my notes+todo inline.

$native_speaker wrote:
 [EN] Below the feature that will be deployed for RCS10. The release is
 expected for [... not sure what does it means ...] (October)

 VECTORS:

 Offline:
 o   Infection of bootable usb keys from UEFI (Antonio)$ The infected usb
 key will drop (release) a scout itself.

This seams to mean that a corrupted UEFI firmware would modify a Tails
device plugged in the machine to infect it. To me it looks like it's
part of Tails can't protect against compromised hardware, modulo
nitpicking wrt. whether firmware is software (which is correct
strictly speaking), or a mere part of the computer hardware (which is
also correct, from the PoV of a Tails system, as it's pre-existing to
Tails starting). We have WIP to clarify our documentation in
this respect.

 o   Infecting USB device which appears to be a bootable disk (Antonio +
 Giovanni)§ It will drop (release) the scout, then it will run
 a wipe.

Seems to be the same, but from a running and already infected
non-Tails OS, when a Tails USB stick is plugged in it. That's more
concerning. We should check if we're communicating clearly enough
that:

 * the OS used to install or upgrade a Tails device can corrupt it
 * plugging one's Tails device in an untrusted OS is dangerous

 o   Infection of Tails USB (Antonio)$ The infection will occur at runtime

This seems to mean an running Tails infecting its boot device.
Totally unclear if they had any remote idea of how to implement that,
back then. Not much we can do about it that is not on our hardening
milestone already, I guess.

 o   New NTFS driver for UEFI infection (Antonio)
 o   Persistent infection also on OSX and signed UEFI (Antonio)

 Network Injection:
 o   New set of external antennas for the TNI (Andrea)
 o   Creation o a mini-TNI (Andrea)$ transportable by a drone, without
 any melting constraints
 o   Creation of a micro-TNI (Andrea)$ HW of a mobile $ It will have a
 subset of the functionality

Cheers,
--
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Hacking Team looking at Tails

[Peter N. Glaskowsky]

I can’t think of any obvious reason this shouldn’t be detectable. Attach a 
suspect USB stick, do not mount it, and compute secure hashes of the partitions.

If the Tails installer doesn’t reliably create consistent partitions, that’s 
something to consider fixing, if it can be fixed.

Even then, we could use an emulator to walk through the boot process on the 
suspect USB stick and see if any code gets executed that isn’t part of Tails.

.png

 On Jul 13, 2015, at 1:24 AM, intrigeri intrig...@boum.org wrote:
 
 Hi,
 
 [redirecting this discussion to tails-dev@boum.org, which is more
 suitable for this discussion = please drop tor-talk@ from the list of
 recipients when replying -- thanks!]
 
 I wrote (12 Jul 2015 13:06:15 GMT) :
 https://wikileaks.org/hackingteam/emails/emailid/25607#efmBTaBTh
 
 Below research points remain outstanding ... 
 
 VECTORS · Offline: [...]
 
 by translate.google.com but obviously not precise but concerning nonetheless.
 
 I got a translation made by a native speaker who's skilled in this
 area, quoting it below with my notes+todo inline.
 
 $native_speaker wrote:
 [EN] Below the feature that will be deployed for RCS10. The release is
 expected for [... not sure what does it means ...] (October)
 
 VECTORS:
 
 Offline:
 o   Infection of bootable usb keys from UEFI (Antonio)$ The infected usb
key will drop (release) a scout itself.
 
 This seams to mean that a corrupted UEFI firmware would modify a Tails
 device plugged in the machine to infect it. To me it looks like it's
 part of Tails can't protect against compromised hardware, modulo
 nitpicking wrt. whether firmware is software (which is correct
 strictly speaking), or a mere part of the computer hardware (which is
 also correct, from the PoV of a Tails system, as it's pre-existing to
 Tails starting). We have WIP to clarify our documentation in
 this respect.
 
 o   Infecting USB device which appears to be a bootable disk (Antonio +
Giovanni)§ It will drop (release) the scout, then it will run
a wipe.
 
 Seems to be the same, but from a running and already infected
 non-Tails OS, when a Tails USB stick is plugged in it. That's more
 concerning. We should check if we're communicating clearly enough
 that:
 
 * the OS used to install or upgrade a Tails device can corrupt it
 * plugging one's Tails device in an untrusted OS is dangerous
 
 o   Infection of Tails USB (Antonio)$ The infection will occur at runtime
 
 This seems to mean an running Tails infecting its boot device.
 Totally unclear if they had any remote idea of how to implement that,
 back then. Not much we can do about it that is not on our hardening
 milestone already, I guess.
 
 o   New NTFS driver for UEFI infection (Antonio)
 o   Persistent infection also on OSX and signed UEFI (Antonio)
 
 Network Injection:
 o   New set of external antennas for the TNI (Andrea)
 o   Creation o a mini-TNI (Andrea)$ transportable by a drone, without
 any melting constraints
 o   Creation of a micro-TNI (Andrea)$ HW of a mobile $ It will have a
 subset of the functionality
 
 Cheers,
 --
 intrigeri
 ___
 Tails-dev mailing list
 Tails-dev@boum.org
 https://mailman.boum.org/listinfo/tails-dev
 To unsubscribe from this list, send an empty email to 
 tails-dev-unsubscr...@boum.org.

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.