On 7/25/14, intrigeri <intrigeri@???> wrote:
> Hi,
>
> Note: what follows is *not* about finding a solution to the last
> de-anonymization vulnerability found in I2P 0.9.13. I trust the I2P
> team will do a proper job at it.
>
>
>
> I2P is software, software has bugs, and some bugs have security
> implications. In the last few days, those of us who were lucky enough
> to read Exodus Intelligence's report have learned that there are quite
> a few such bugs in I2P. I can't say much publicly right now, and I'm
> no Java programmer, but given how these bugs look like, I would not be
> surprised if there were quite a few other similar security issues
> lurking somewhere in the I2P codebase. Shit happens, and oh well,
> we're shipping Pidgin and a Firefox-based browser, too.
Indeed.
>
> On the long-term, I'd like us to be able to go on shipping I2P in
> Tails, without fearing too much about it.
>
> So, the main goals I have in mind are:
>
> 1. making it harder, for an attacker who compromises I2P running in
> Tails, to upgrade their attack to anything non-I2P;
>
A compromose of i2p is game over on Tails from an anonymity
perspective. It has access to files on the disk, it has access to the
complete network and so on. What do you mean by 'upgrade' their
attack? Do you mean, for example, rooting the box? Keeping files
around? Running arbitrary code?
>
> 2. making it harder, for someone attacking a Tails user's web
> browsing over Tor, to take advantage of bugs in the I2P router
> console;
>
That is an important goal, I fully agree.
> 3. protecting the Tails users who don't intend to use I2P at all,
> from vulnerabilities in I2P, by making it harder, for an attacker,
> to start I2P in Tails, or to trick a user into doing it.
>
I think that means we need to audit the default state of the system
even if we're not running i2p. The system is ready for i2p to run and
as a result, it has a lot of permissive behavior that is not strictly
required.
> Regarding #1:
>
> a) On the filesystem and privilege escalation side, I think we should
> sandbox I2P better. We're working on integrating AppArmor in
> Debian and Tails, and I think I2P would be a good candidate for
> confinement. @I2P folks: do you already have anything in the works
> in this area? Anyone else?
>
I would say that we should disable the i2p rules in the firewall
unless a user positively affirms that they want to run i2p. As it
stands now - there is a full user that is able to talk to the
internet, regardless of the state of i2p. If it isn't running, we
should not have the following in ferm.conf:
# White-list access to I2P
# For more information, see
https://tails/boum.org/contribute/design/I2P and
https://geti2p.net/ports
daddr 127.0.0.1 proto tcp syn mod multiport
destination-ports (2827 4444 4445 6668 7656 7657 7658 7659 7660 8998)
{
mod owner uid-owner amnesia ACCEPT;
}
# i2p is allowed to do anything it wants to.
mod owner uid-owner i2psvc ACCEPT;
We need some way to modify ferm.conf when a user does wish to use i2p.
It isn't started by default - so it seems clear that we don't need
these firewall rules by default unless we cannot change ferm.conf for
some reason.
> b) On the network side (mostly de-anonymization), the solution that
> springs to mind would be to torify I2P. I'm told it would not work
> well and be ugly, but it's completely unclear to me what it means
> in practice, and I'd like to hear well-documented experience
> reports. Note that Liberte Linux did torify I2P back when they
> shipped it, so it must somehow work, I guess. Anyone?
>
I think torifying i2p is a fine middle ground for accessing i2p
services. That would have stopped part of the impact of the i2p bug in
question. Still - it isn't enough. Code execution in i2p as detailed
on the Exodus blog would not be stopped by Torification of i2p. The
impact of such a bug would not be completely minimized either -
arbitrary code on the system can still read out unique identifiers. It
can probably jump across system boundaries quite easily at the moment
- especially with the LAN rules in place. :(
> And, if this doesn't work, any alternative solution, other than
> crossing fingers?
>
> Regarding #2, I think we should get rid of the Tor/I2P/LAN mix-up in
> the Tor Browser we ship. The LAN part still needs some more thought
> and discussion, but IMO the I2P part of the FoxyProxy configuration
> should simply go away. The solution I have in mind would be to create
> another browser dedicated to the I2P, running under a dedicated UID,
> and that can only talk to the I2P proxy and router console. Note that
> this would also help in addressing #1, possibly.
That seems like a fine thing for isolating i2p browser bugs but I'm
not clear that this will solve the actual bugs. It would only ensure
that those impacted are impacted by a special i2p enabled browser, so
all i2p users are still in harm's way. That seems less than great but
better than nothing.
I've personally deleted all the i2p (and LAN) rules from my FoxyProxy
configuration.
>
> Technically speaking, I guess it could be easily implemented with the
> same tricks we use for the Unsafe Browser. The only problem I expect
> is a usability one: how to share files between the `amnesia' user and
> this I2P browser. The good news is that we'll have to tackle the very
> same problem if we ever sandbox applications using Linux namespaces,
> and if we move the LAN browsing out of the Tor Browser. Both seem to
> be due to happen at some point.
>
> Regarding #3, I think we should replace the sudo credentials that
> allow the `amnesia' user to start I2P, with an I2P option in Tails
> Greeter. I assume the new Greeter that's currently worked on would
> allow this.
>
I agree. I was really surprised to see that amnesia can start i2p with
sudo and no user interaction. Generally, I think this calls for an
audit of everything in /etc/sudoers.d/ and a different discussion
should be had about the various sudoers.d files.
> So, these are plenty of ideas, of potential solutions that could be
> worth discussing. I'm not *that* interested in the technical details
> of these solutions right now. What I'd like to happen now is to decide
> about a strategy and a time-line; and, I'd like to get a clearer view
> of the commitments and responsibility boundaries regarding I2P in
> Tails. In other words:
>
> * What threat, among the aforementioned ones (and those I forgot),
> do we want to address *now* to go on shipping I2P?
>
The firewall should be closed by default and part of the work to use
i2p should be to fix dynamically changing it when a user wishes to use
i2p.
> * If we keep I2P without adding any protection immediately, when do
> we expect *which* protections to be ready? (reality check: we won't
> have AppArmor before October; I guess the Greeter won't be ready
> earlier either)
I think this is probably not a wise idea. I really suggest a hotfix
for all users as soon as possible.
>
> * On the Tails side, basically everyone skilled enough to work on
> this have enough commitments until the end of the year, so if we
> decide "we want $this to happen to keep I2P", then someone else
> will have to step up. So: would I2P folks (I'm mainly thinking of
> KillYourTV here), or anyone else, want to take responsibility for
> part, or all, of the improvements we may decide are needed?
> Of course, anyone volunteering will be involved in the
> decision-making process :)
>
I'm happy to try to review such fixes; my i2p knowledge could use a
refresh and my time is limited but I'm happy to help. Part of my
concern here is the router console. If amnesia can access it, it can
effectively do whatever i2p's user can do, right? This is a design
issue that has serious consequences. It isn't wrong but it might make
sense to have a specific i2p router console application - it could
even be a sandboxed web view, for example.
> * Worst case, for how long would it be acceptable (even if sad) to
> drop I2P from Tails until the protections we want are ready for
> prime-time?
It seems prudent to ship a hotfix as soon as possible and keep i2p
dropped, with a tighter firewall until the security issues are fixed.
I've provided a patch privately to resolve this issue but it isn't
perfect by any means. Is this patch being considered? I don't feel too
strongly about it - I merely wanted to contribute something helpful
during the stressful evening.
All the best,
Jacob
