[9fans] Drawterm and security

[9fans] Drawterm and security

[Brian L. Stuart]

I'm about to drive my fist through the monitor.  I think
I'm generally a fairly intelligent person and I generally
understand the Plan9 paper on security, but I'm having
a serious disconnect between that and how it's implemented
in practice.  Last night I was successfully connected between
a Linux box and my Plan9 file/cpu server with drawterm.
This morning I realized that I was unable to authenticate
to sources from the fs/cpu server so started to try to
fix my /lib/ndb/local to address the problem.  Nothing
seemed to work and worse yet, now drawterm is broken with
the infamous "cannot authenticate with p9" message even when
returning to the same /lib/ndb/local.  What exactly are the
necessary and sufficient conditions for making drawterm work
and likewise for access to sources?  auth/debug appears to be
fine and /sys/log/auth also seems fine.  I'm assuming that the
auth=sources... line must be there.  Does it break things to
have additional auth=bootes and authdom=home in the section
that describes the local net?  factotum is the only piece of
the current security system that hasn't seemed like black
magic to me.  Any wisdom is welcome.  Even a recipe would
be welcome at this point.

Brian L. Stuart

Re: [9fans] Drawterm and security

[andrey mirtchovski]

> Even a recipe would be welcome at this point.

Ingredients:

    * 1 part Vodka
    * 1 part Tequila
    * 1 part Rum
    * 1 part Gin
    * 1 part Triple sec
    * 1 1/2 part Sour mix
    * 1 splash Coca-Cola

Mixing instructions:

Mix ingredients together over ice in a glass.  Pour into shaker and
give ONE brisk shake.  Pour back into glass and make sure there is a
touch of fizz at the top.  Garnish with lemon.

as for authentication, what do you mean by 'auth/debug is fine'
exactly?  is auth/keyfs running?  what's the drawterm message?  do you
have factotum running?

Re: [9fans] Drawterm and security

[Russ Cox]

After editing /lib/ndb/local (or any files in /lib/ndb),
it is a good idea to do

    echo -n refresh >/net/cs

to tell cs to reload the ndb files *now*.  It will eventually
notice that they have changed and reload them itself,
but not necessarily immediately.  That could well be the
cause of your confusion and frustration.

Russ

Re: [9fans] Drawterm and security

[blstuart]

In message <8e10ef025f295ae275886fa840d1bc1b@9netics.com>, Skip Tavakkolian wri
tes:
>With drawterm, everything is running on the cpu, and drawterm
>is just 'exportfs'ing your local namespace (for things like keyboard,
>mouse, etc.) I'm guessing that YOUR factotum (your authentication
>agent) is not running.  I've attached dt_factotum, which I
>got from geoff.  You run it on the cpu (in you're drawterm session),
>once you've successfully drawterm'ed in.

The problem is that I'm not getting that far.  drawterm
bails a few seconds after I enter the correct password.
The file/cpu server does have a factotum running as user
bootes.  I get the same behavior whether I try to log
in as either bootes or as myself.

Still, I'll hang on the script.  Looks like it will be
useful when I do get successfully drawterm'ed in.

Thanks,
Brian L. Stuart

Re: [9fans] Drawterm and security

[blstuart]

In message <ee9e417a0502191058484e4422@mail.gmail.com>, Russ Cox writes:
>After editing /lib/ndb/local (or any files in /lib/ndb),
>it is a good idea to do
>
>    echo -n refresh >/net/cs

Thanks for the tip.  I had been resorting to killing and
restarting cs, and even frequent reboots.  Are there any
other processes that need to know if there are changes
there?

That had certainly been part of the frustration.  I still
feel like I'm editing /lib/ndb/local using a random walk,
however.

Thanks,
Brian L. Stuart

[9fans] Venti security in view of SHA-1 exploit

[Paul Lalonde]

Has anyone given any thoughts on how Venti might be affected by the
recent weakening of the SHA-1 hash?
I can see one exploit in which a different block is returned from a
compromised venti server, that I accept because the fingerprint matches
the requested fingerprint.  The issue of turnaround time isn't really
there as files live on Venti for a long time, and a compromised server
could at its leisure find a collision for some block I'm submitting.
The likelihood of such an exploit seems small, but should we be looking
for a better Venti hash?

Paul

Re: [9fans] Drawterm and security

[Russ Cox]

> Thanks for the tip.  I had been resorting to killing and
> restarting cs, and even frequent reboots.  Are there any
> other processes that need to know if there are changes
> there?

You can echo -n refresh >/net/dns too, but you weren't
changing DNS-related stuff.

Russ

Re: [9fans] Venti security in view of SHA-1 exploit

[andrey mirtchovski]

> Has anyone given any thoughts on how Venti might be affected by the
> recent weakening of the SHA-1 hash?
> I can see one exploit in which a different block is returned from a
> compromised venti server, that I accept because the fingerprint matches
> the requested fingerprint.  The issue of turnaround time isn't really
> there as files live on Venti for a long time, and a compromised server
> could at its leisure find a collision for some block I'm submitting.
> The likelihood of such an exploit seems small, but should we be looking
> for a better Venti hash?
>
> Paul

things looked optimistic a few months ago:

http://lists.cse.psu.edu/archives/9fans/2004-August/037686.html
http://lists.cse.psu.edu/archives/9fans/2004-August/037695.html

Re: [9fans] Venti security in view of SHA-1 exploit

[Paul Lalonde]

On 19-Feb-05, at 11:26 AM, andrey mirtchovski wrote:
> things looked optimistic a few months ago:

But the question is should we, not could we.

The easy part is replacing the hash function.

The ugly part is rebuilding existing venti arenas, particularly
indexing data stored in other blocks; in practice this means a
conversion tool for any tools that wrote to venti - vac, fossil, and
I'm sure others.

Paul

Re: [9fans] Drawterm and security

[Skip Tavakkolian]

With drawterm, everything is running on the cpu, and drawterm
is just 'exportfs'ing your local namespace (for things like keyboard,
mouse, etc.) I'm guessing that YOUR factotum (your authentication
agent) is not running.  I've attached dt_factotum, which I
got from geoff.  You run it on the cpu (in you're drawterm session),
once you've successfully drawterm'ed in.

term% cat $home/bin/rc/dt_factotum
#!/bin/rc

if (! test -f /srv/factotum.$user)
	auth/factotum -s factotum.$user
mount -b /srv/factotum.$user /mnt

> I'm about to drive my fist through the monitor.  I think
> I'm generally a fairly intelligent person and I generally
> understand the Plan9 paper on security, but I'm having
> a serious disconnect between that and how it's implemented
> in practice.  Last night I was successfully connected between
> a Linux box and my Plan9 file/cpu server with drawterm.
> This morning I realized that I was unable to authenticate
> to sources from the fs/cpu server so started to try to
> fix my /lib/ndb/local to address the problem.  Nothing
> seemed to work and worse yet, now drawterm is broken with
> the infamous "cannot authenticate with p9" message even when
> returning to the same /lib/ndb/local.  What exactly are the
> necessary and sufficient conditions for making drawterm work
> and likewise for access to sources?  auth/debug appears to be
> fine and /sys/log/auth also seems fine.  I'm assuming that the
> auth=sources... line must be there.  Does it break things to
> have additional auth=bootes and authdom=home in the section
> that describes the local net?  factotum is the only piece of
> the current security system that hasn't seemed like black
> magic to me.  Any wisdom is welcome.  Even a recipe would
> be welcome at this point.
>
> Brian L. Stuart

Re: [9fans] Venti security in view of SHA-1 exploit

[Tim Newsham]

> But the question is should we, not could we.

The attacks I can think of:
   - attacker with access to venti anticipates a particular block
     will be stored in the future.  He burns cycles and finds a
     collision and stores his corrupt block first.  Later you
     store your block and when you fetch the file you stored
     one of the blocks is bad.
   - a malicious venti server targets some stored blocks and
     burns cycles to replace them with bad blocks.
   - a man-in-the-middle sees a block go buy and targets it for
     corruption.  He burns cycles and finds a collision.  Next
     time the block is requested he injects the bad block.

All of this assumes the attacker gets to choose which block
to cause a collision on.  I havent followed the previous MD5
work, does anyone know if this is the case?  If the attack
is limited to just finding any two blocks that collide then
neither of these attacks would be viable.

In the case of SHA1 the scant information released so far
indicates its still a 2^69 attack.  That's a LOT of operations.

It sounds to me like the need to switch from SHA1 is not
pressing right now, especially since the details of the
attack have not yet been published.

What scares me a little though is that some people are
recommending dropping the "collision-proof" requirements
of hashes.  If that were to happen I wonder what the implications
would be for any hash-addressable storage systems.

> Paul

disclaimer: I'm a security guy, but definitely no crypto expert.
Tim N.

Re: [9fans] Venti security in view of SHA-1 exploit

[Russ Cox]

Conversion is made quite easy (compared to other systems
I am familar with) because the blocks are tagged with their type
(data, SHA1 hashes of data, SHA1 hashes of hashes of data)
and the block tree is a standardized format used by all clients,
so conversion can happen independent of the program that wrote
the data.  After converting the data, all the clients and the server
would have to be rebuilt with the new hash function.

It is not necessary to write a separate program to convert fossil
data, vac data, etc.

Some day it will be necessary to worry about this.  It is not today.

Russ

Re: [9fans] Drawterm and security

[blstuart]

In message <ee9e417a05021911205354182a@mail.gmail.com>, Russ Cox writes:
>You can echo -n refresh >/net/dns too, but you weren't
>changing DNS-related stuff.

Cool.  What about changes to authdom?  Who uses authdom
and how?  In response to Andrey's questions (which I seem
to have sent just to him instead of the list), my local
file has the normal auth=sources... line and it also
has an authdom=home in the section for my local network.
I'm not quite sure what it means for both of them to be
there.  In fact, when I first set the system up, I commented
out the auth=sources line.  But today, I figured that was
at the heart of my problem getting replica/pull to work.

Brian L. Stuart

Re: [9fans] Drawterm and security

[andrey mirtchovski]

> In message <ee9e417a05021911205354182a@mail.gmail.com>, Russ Cox writes:
>>You can echo -n refresh >/net/dns too, but you weren't
>>changing DNS-related stuff.
>
> Cool.  What about changes to authdom?  Who uses authdom
> and how?  In response to Andrey's questions (which I seem
> to have sent just to him instead of the list), my local
> file has the normal auth=sources... line and it also
> has an authdom=home in the section for my local network.
> I'm not quite sure what it means for both of them to be
> there.  In fact, when I first set the system up, I commented
> out the auth=sources line.  But today, I figured that was
> at the heart of my problem getting replica/pull to work.
>
> Brian L. Stuart

i don't seem to have received your message. i blame the university's email servers.

for authdom= the only requirement that's really important is to make
sure you've synchronized it with what cpu server user (bootes in most
cases) thinks it's running in.  i.e.  when you boot it make sure your
authdom= in nvram is the same as the authdom= entry in ndb for the
network you're booting in:

ipnet=ucalgary ip=136.159.220.0 ipmask=255.255.255.0
	proto=tcp
	[...]
	authdom=plan9.ucalgary.ca

when i invalidate the nvram (or change the password) i supply
plan9.ucalgary.ca as the authdom on the next boot of the cpu server.

andrey

Re: [9fans] Drawterm and security

[Brian L. Stuart]

Let's try this again.  It didn't seem to get out before.

In message <0857c7e34289332af716f9b0ef5a55c2@plan9.ucalgary.ca>, andrey mirtcho
vski writes:
>> Even a recipe would be welcome at this point.
>
>Ingredients:
>
>    * 1 part Vodka
>    * 1 part Tequila
>    * 1 part Rum
>    * 1 part Gin
>    * 1 part Triple sec
>    * 1 1/2 part Sour mix
>    * 1 splash Coca-Cola

Truely tempting.

Well, I was going to repeat all the stuff I had tried to send before,
but suddenly things are working for drawterm.  The last step was
to invalidate the nvram, reboot and reset all the passwords.  I'm
not sure how things got mangled, but drawterm is now working.
replica/pull still isn't however.  I definitely have the auth=sources
line in /lib/ndb/local now.  But even before factotum asks for
a user and password, I'm getting:

srv tcp!sources.cs.bell-labs.com: mount failed: authentication failed

I get the same thing if I manually try to 9fs soruces.  Any ideas on
that one?

Thanks to everyone for your help.  The really frustrating part of
all of the authentication stuff is that I don't seem to yet see
the connections between fault symptoms and causes.  I still don't
know why wiping the nvram and resetting everything has made drawterm
happy.

Brian L. Stuart

Re: [9fans] Venti security in view of SHA-1 exploit

[boyd, rounin]

OTOH the reason 2DES was dumped for 3DES is that there
is a theoretical, by fairly impractical, attack.

i am not saying that we should worry about SHA-1 today,
but we should be aware.
--
MGRS 31U DQ 52572 12604

Re: [9fans] Venti security in view of SHA-1 exploity

[William Josephson]

On Sat, Feb 19, 2005 at 11:25:52PM +0100, boyd, rounin wrote:
> OTOH the reason 2DES was dumped for 3DES is that there
> is a theoretical, by fairly impractical, attack.

To be more precise: 2DES doesn't buy you much over DES,
while 3DES would appear to.

 -WJ

Re: [9fans] Venti security in view of SHA-1 exploity

[boyd, rounin]

> To be more precise: 2DES doesn't buy you much over DES,
> while 3DES would appear to.

nope, there is a meet in the middle attack for 2DES and going
to 3DES is trivial to implement.
--
MGRS 31U DQ 52572 12604

Re: [9fans] Venti security in view of SHA-1 exploit

[Bruce Ellis]

from slashdot

"Using a modified DES Cracker, for the small sum of up to $38M, SHA-1
can be broken in 56 hours, with current computing power."

so there you go.

brucee

Re: [9fans] Venti security in view of SHA-1 exploit

[Tim Newsham]

> "Using a modified DES Cracker, for the small sum of up to $38M, SHA-1
> can be broken in 56 hours, with current computing power."
>
> so there you go.

Well if slashdot said it, then who am I to argue? :)
(How is this related to DES again?)

> brucee

Tim N.

Re: [9fans] Venti security in view of SHA-1 exploit

[Karl Magdsick]

Note that the work factor is 2**69, being compared to 2**80 (birthday
attack).  In other words, SHA-1 is still believed to be weakly
collision resistant.  In other words, it still takes an attacker on
the order of 2**160 operations to find a collision between two blocks
if one of the blocks is pre-determined.

Strong collision resistance implies weak collision resistance and
you'd prefer a strongly collision resistant hash function.  A
demonstration that SHA-1 is not strongly collision resistant means
researchers are closer to demonstrating that SHA-1 is not weakly
collision resistant.  However, for fossil, you only need weak
collision resistance for most applications.

If you're worried about an attacker being able to create one file and
give it to you and being able to corrupt it later, then worry.

This attack does not seem to have direct implications for most
applications of fossil.

The sky isn't falling.  You'll probably want to start thinking about
changing hash functions once other hash functions start getting more
scrutiny as researchers start debating SHA-1 replacements.  The SHA-2
family (SHA-224,SHA-256,SHA-384, and SHA-512) have structure similar
to eachother, but perhaps different enough from SHA-1 to not be
vulnerable.  In any case, it would be brash to change hash functions
any time soon.


-Karl


On Sun, 20 Feb 2005 10:21:16 +1100, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> from slashdot
>
> "Using a modified DES Cracker, for the small sum of up to $38M, SHA-1
> can be broken in 56 hours, with current computing power."
>
> so there you go.
>
> brucee
>

Re: [9fans] Venti security in view of SHA-1 exploit

[Karl Magdsick]

> All of this assumes the attacker gets to choose which block
> to cause a collision on.  I havent followed the previous MD5
> work, does anyone know if this is the case?  If the attack
> is limited to just finding any two blocks that collide then
> neither of these attacks would be viable.
>
> In the case of SHA1 the scant information released so far
> indicates its still a 2^69 attack.  That's a LOT of operations.

It would appear that it is the latter type of attack, limited to only
finding two random blocks that collide.  (The expected work factor for
this type of attack is 2**80 for an ideal 160-bit hash function.)

As I remember, the SHA-0 attack required that the blocks were
indentical except for the most significant bits of a few adjascent
32-bit (big-endian) words.  The non-identical bits had to fit a very
special relation (related to the GF2**16 primitive polynomial used in
the SHA-0 block expansion function).  The attack consisted of creating
lots and lots of blocks fitting these properties and checking if any
of them hashed to the same value.  Supposedly, the SHA-1 break is
related to the SHA-0 break, so it's mostly an academic problem for the
time being.

On the other hand, a collision with a work factor of 2**69 indicates
weaknesses in SHA-1.  Researchers will likely find better and better
ways to exploit these weaknesses.  They may also find ways of
exploiting these weaknesses to break its weak collision resistance or
its one-way properties.  They've basically found a way to speed up
bruit force by 2048 times, which isn't too bad.  The main problem is
that it's a bad omen.

SHA-256, Tiger, and Whirlpool are probably the most likely candidates
for SHA-1 replacements, maybe with truncated outputs.  However, SHA-1
and MD-5 are the most scrutinized hash functions.  These candidates
may all have much more serious problems that are relatively easy to
find.  In particular, Whirlpool is related to Rijndael, which is
vulnerable to XSLT attacks.  It will likely be a while before there's
a consensus on which hash should be used to replace SHA-1.



-Karl

Re: [9fans] Venti security in view of SHA-1 exploity

[William Josephson]

On Sat, Feb 19, 2005 at 11:48:06PM +0100, boyd, rounin wrote:
> >To be more precise: 2DES doesn't buy you much over DES,
> >while 3DES would appear to.
>
> nope, there is a meet in the middle attack for 2DES and going
> to 3DES is trivial to implement.

Actually, if you look at the numbers you will see that the
meet in the middle attack makes 2DES roughly equivalent to
DES, but that that is not the case for 3DES.

 -WJ

Re: [9fans] Drawterm and security

[Robert Raschke]

Skip Tavakkolian wrote:
> term% cat $home/bin/rc/dt_factotum
> #!/bin/rc
>
> if (! test -f /srv/factotum.$user)
> 	auth/factotum -s factotum.$user
> mount -b /srv/factotum.$user /mnt

Hmm, all I do is start a plain auth/factotum in my profile when I
recognise that I'm running a drawterm connection.  What is the reason
for ensuring an explicit service name?  By default it doesn't announce
a service, and if I understand correctly, the /mnt/factotum/ is going
to be the correct one (i.e., not the one mounted by bootes) for the
drawterm session.

About the original problem of factotum not prompting for passwords,
one of the issues I had in the early days was that factotum attempted
to collect my password from the console.  And that didn't work when I
connected via drawterm.  I got around that by starting fgui explicitly
via 'window -hide auth/fgui' in my riostart script.

Robby

Re: [9fans] Drawterm and security

[geoff]

> What is the reason for ensuring an explicit service name?

As usual, one posts a service to permit (or at least encourage)
sharing.  In this case, one also wants to avoid a possible
collision with an existing (bootes) /srv/factotum on a CPU server.
By creating a /srv/factotum.$user at first login, it's
then possible for later logins by $user to share the same
factotum (by just mounting /srv/factotum.$user on /mnt).

It does make one's profile (or at least my profile) a little
messier, probing for suitable existing factota in /srv and
/mnt/term/srv.

Re: [9fans] Drawterm and security

[Brian L. Stuart]

In message <ee9e417a05021914422bf17403@mail.gmail.com>, Russ Cox writes:
>> I almost literally heard the bell ring this time.  So
>> when I try to initiate an authentication, it's up to the
>> server to tell me what authentication domain he wants to
>> use.  Then I look up to find a auth= autodom= entry so
>> that I know who to talk to in order to do authenticate
>> in that domain.  So if I have an authdom=home entry in my
>> local network section, then anyone who wants to connect
>> to my server will be told to authenticate using the
>> home domain.  It's then up to the client to know what
>> auth server to use.
>
>All this is true except that the choice of authdom=home
>does not come from your local network section.  The choice
>of authdom comes from factotum, and it offers the client
>a list of possible domains.  In particular, it offers any domain
>on a p9sk1 key that isn't marked with role=client.

That makes sense.  So the putting auth= and authdom= into
the local network section is to tell your clients the
appropriate domain->server mapping for your network,
right?  It also raises the question, where does factotum
get that first key so that he has a dom to send out-
from nvram?

Thanks,
Brian L. Stuart

Re: [9fans] Drawterm and security

[Russ Cox]

> >When you try to connect to sources (for example, you
> >do a replica/pull, or 9fs sources) it connects to the
> >machine and the machine asks you to authenticate to
> >the outside.plan9.bell-labs.com authdom.
>
> I almost literally heard the bell ring this time.  So
> when I try to initiate an authentication, it's up to the
> server to tell me what authentication domain he wants to
> use.  Then I look up to find a auth= autodom= entry so
> that I know who to talk to in order to do authenticate
> in that domain.  So if I have an authdom=home entry in my
> local network section, then anyone who wants to connect
> to my server will be told to authenticate using the
> home domain.  It's then up to the client to know what
> auth server to use.

All this is true except that the choice of authdom=home
does not come from your local network section.  The choice
of authdom comes from factotum, and it offers the client
a list of possible domains.  In particular, it offers any domain
on a p9sk1 key that isn't marked with role=client.

Russ

Re: [9fans] Drawterm and security

[Brian L. Stuart]

In message <Pine.BSI.4.61.0502191055110.3971@malasada.lava.net>, Tim Newsham wr
ites:
>When you try to connect to sources (for example, you
>do a replica/pull, or 9fs sources) it connects to the
>machine and the machine asks you to authenticate to
>the outside.plan9.bell-labs.com authdom.

I almost literally heard the bell ring this time.  So
when I try to initiate an authentication, it's up to the
server to tell me what authentication domain he wants to
use.  Then I look up to find a auth= autodom= entry so
that I know who to talk to in order to do authenticate
in that domain.  So if I have an authdom=home entry in my
local network section, then anyone who wants to connect
to my server will be told to authenticate using the
home domain.  It's then up to the client to know what
auth server to use.

Somehow I never caught that part of it.  I think I can
now classify it as grey magic instead of black magic.
I'm still fuzzy on some bits, but it's getting a little
clearer.

Thanks,
Brian L. Stuart