LTSPFS security is broken

in ltsp5 ltspfs uses the ssh tunnel ldm establishes instead of the internal xauth mechanism, the -a option is for backwards comaptibility with ltsp 4.x only

As part of the boot process, the thin client runs;

            /usr/bin/ltspfsd -a

At this point, it is listening on 0.0.0.0:9220.

Anyone on the network or the server can then access this port via the thin client's native IP address.

??

to do what ?
connecting to that port is pointless if you dont know the names and paths for the exported filesystems ltspfsd is offering ...

Ok, if I boot a thin client (without logging in or doing anything clever) on the server (or indeed any intelligent machine on the network) I can do the following;

ltsp <address>:/var/run/drives /mnt/localdev/mountpoint

And I have full access to the client's device , USB key in this case ... ??

To reproduce on a random workstation (taken from my Bash session);

sudo apt-get install ltspfsd

modprobe fuse

ltspfs 10.1.0.220:/var/run/drives /mnt/root

df -> ltspfs 452440 44 452396 1% /mnt/root

ls -la /mnt/root/usbdisk-sdc1
total 384
drwxr-xr-x 2 root root 2048 1970-01-01 01:00 .
drwxr-xr-x 4 root root 80 2007-08-20 12:11 ..
-rwxr-xr-x 1 root root 0 2007-08-18 14:47 new file
-rwxr-xr-x 1 root root 390384 2007-04-18 18:26 Scan0001.jpg

(!)

I can confirm this one here. Interestingly enough, ltspfsd depends on ltsp-client, which fails to install (leaving a broken dependency on the system), but ltspfsd works fine anyway.

We've just discussed this in #ltsp.

The old LTSP used the xauth key, but this broke because of ssh forwarding. We'll fix this, and get it going.

I'll work on it tonight.

Scott

Hi! How is this coming along?

Fix is in my tree. An mcookie is generated for the terminal, and set as an xprop during login. Client must pass correct mcookie for connect to happen.

Scott

Will this fix be ported to Feisty security-updates? It is quite a large security hole...

Johnathon

----- "Scott Balneaves" <email address hidden> wrote:
> Fix is in my tree. An mcookie is generated for the terminal, and set
> as
> an xprop during login. Client must pass correct mcookie for connect
> to
> happen.
>
> Scott
>
> ** Changed in: ltsp (Ubuntu)
> Status: In Progress => Fix Committed
>
> --
> LTSPFS security is broken
> https://bugs.launchpad.net/bugs/133635
> You received this bug notification because you are a direct
> subscriber
> of the bug.

In ltspfs-0.5

This is vulnerable in feisty -- will you be able to backport a fix for 0.4.3-0ubuntu6 ? Thanks!

Hi,

Is this going to be fixed in Fiesty/Dapper, which are both still in security support? (Our servers are running a mixture of Dapper, Edgy, Fiesty & Gusty, depending at what time they were put in, and whether they need to upgrade for new packages like apache 2.2)

Ubuntu Edgy Eft is no longer supported, so a SRU will not be issued for this release. Marking Edgy as Won't Fix.

Really _awesome_ security policy guys! Ignore a hole, till the releases its in are out of support. You know, I'd expect that tactic from MS Windows, not from Ubuntu.

There we go, I knew it wasn't just me getting pissed off with Ubuntu for no reason ... ;-)

----- Original Message -----
From: "Johnathon" <email address hidden>
To: <email address hidden>
Sent: Thursday, July 24, 2008 8:45:06 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: [Bug 133635] Re: LTSPFS security is broken

Really _awesome_ security policy guys! Ignore a hole, till the releases
its in are out of support. You know, I'd expect that tactic from MS
Windows, not from Ubuntu.

--
LTSPFS security is broken
https://bugs.launchpad.net/bugs/133635
You received this bug notification because you are a direct subscriber
of the bug.

--
Managing Director, Encryptec Limited
Tel: 0845 5082719, Mob: 0785 3305393
Email: <email address hidden>
Statements made are at all times subject to Encryptec's Terms and Conditions of Business, which are available upon request.

dapper never had ltspfs support, seems feisty just slipped through, sorry for that, we will provide a fix for it asap (note that all newer releases have the fix included by default and that it really only affects users on the same server since ltspfs will only accept connections from the server ip anyway in ltsp5)

Could someone please set this at Won't Fix for feisty as it's no longer supported?

Marked Feisty task as Won't Fix as Feisty is EOL

...

And, again, this bug was ignored for 4 and a half months, till the vulnerable release went EOL.

Again, "Really _awesome_ security policy guys!"
Again, "I'd expect that tactic from MS Windows, not from Ubuntu."

I know you guys are manically busy working on new features, I know back-porting security fixes is a right PITA, slow, boring, and what you *don't* want to be spending time on. But by not patching it, you're letting people's data swing free in the breeze, with a documented problem available on the net for exploitation.

How can I make you take what's happened here seriously? Post this on my blog, and by extension the Ubuntu UK planet? Post on the general Ubuntu mailing lists? Post any exploits that I help confirm later on cracker forums?
Should you take this sort of security hole seriously? Because you obviously haven't.

If I knew how this stuff worked, if I was able to learn this stuff myself, I'd try to help fix it. But as it is, my programming knowledge is basic, and I accept the description of myself as "not a natural programmer" as truth.

Johnathon wrote:
> ...
>
> And, again, this bug was ignored for 4 and a half months, till the
> vulnerable release went EOL.
>
> Again, "Really _awesome_ security policy guys!"
> Again, "I'd expect that tactic from MS Windows, not from Ubuntu."
>
> I know you guys are manically busy working on new features, I know back-
> porting security fixes is a right PITA, slow, boring, and what you
> *don't* want to be spending time on. But by not patching it, you're
> letting people's data swing free in the breeze, with a documented
> problem available on the net for exploitation.
>
> How can I make you take what's happened here seriously? Post this on my blog, and by extension the Ubuntu UK planet? Post on the general Ubuntu mailing lists? Post any exploits that I help confirm later on cracker forums?

One thing is for sure, sarcastic and rude remarks at the people who work
their asses off to fix this stuff sure isn't a very good method to
getting it fixed.

Wow. What arrogance. IANAP either, probably have less experience than
you in the field - but I sure now how to use a bit of elbow grease
instead of spinning your wheels for everyone to hear to get things
accomplished.

Isn't it amazing how some people will still continue to defend the indefensible, just because their ears hurt.

If Ubuntu were billed as a charity, I might tend to agree that people working for free shouldn't need to take any sort of hit for shoddy workmanship. Or, if Ubuntu were billed as "unfit for business consumption", then again I might be inclined to agree that letting this sort of thing pass might be acceptable.

However the "Ubuntu Promise" on the home page includes;
"Ubuntu will always be free of charge, including enterprise releases and security updates."

The caveat "assuming we have the time to worry about security updates" is strangely missing.

In this particular instance it's no longer an issue for me as the customer has reverted to Windows. It is however a sign that it's not safe to trust Ubuntu to fix critical security flaws even after they've been reported .. it seems that waiting until the release's end of life then marking the issue as obsolete is preferred.

Don't get me wrong, I'm not having a go at any of the developers / maintainers involved and lay no blame at their door , this is 100% an issue for Ubuntu / Canonical. They are making promises to users and potential users that they are (IMHO) not keeping and it's going to come down to their style of organisation, management and accountability.
[or lack of ..]

You will note that in this instance users have taken the trouble to actually document and report a critical security issue, indeed over 15 months ago. My understanding of Open Source and the Open Source community is that they have done "their" bit, only to find they have wasted their time because the developers 'responsible' were either too busy or didn't think it was worth their while.

It would be nice if Ubuntu would decide whether they're offering a commercial grade product, or a hobby project worked on by volunteers "if and when they have time".

.. am I to be called sarcastic, arrogant, lazy and rude too ??
.. or perhaps when committed Linux people start to make unhappy noises, maybe there is an issue somewhere ??
.. "good" developers (IMHO) pay more attention to the content and less to the tone, users often become very frustrated when faced with 'broken' software. I doesn't however make them wrong.

On an entirely separate note (not!) , why Ubuntu keep pushing out new / broken releases instead of trying to fix what they already have and make it stable, is completely beyond me. I've seen quite a few "fixed in Intrepid" notices and as a result, I'm now running "intrepid". I can see where they got the name ...

Not that I know, but I don't think you understand the general process of using your (limited) resources as effectively as possible under a priority-based system for such an enormous project as Ubuntu.

I'm just a normal sysadmin and business owner, read: IANAP. But I do understand that given the variables in this bug, given the corner-case nature of installed versions of software, and the requirements to execute the vulnerability itself, the priority was probably (unoficially) set at low, given the (hundreds of?) other pressing security issues that most likely affected many more users than in this one. Again, that's just my own guess, I really don't know. But you see my point, I hope.

I also have learned myself that harsh tone and threats upstream don't do a whole hell of a lot of good. Rather, why not point your rather large supply of energy in a more positive direction, such as maybe expressing your concerns to the right people, instead of, as you see it anyway, an ignored bug report. Be the one to push the changes you want to see. Remember the definition of Ubuntu.

Jordan Erickson wrote:
> Johnathon wrote:
>> ...
>>
>> And, again, this bug was ignored for 4 and a half months, till the
>> vulnerable release went EOL.
>>
>> Again, "Really _awesome_ security policy guys!"
>> Again, "I'd expect that tactic from MS Windows, not from Ubuntu."
>>
>> I know you guys are manically busy working on new features, I know back-
>> porting security fixes is a right PITA, slow, boring, and what you
>> *don't* want to be spending time on. But by not patching it, you're
>> letting people's data swing free in the breeze, with a documented
>> problem available on the net for exploitation.
>>
>> How can I make you take what's happened here seriously? Post this on my blog, and by extension the Ubuntu UK planet? Post on the general Ubuntu mailing lists? Post any exploits that I help confirm later on cracker forums?
>
> One thing is for sure, sarcastic and rude remarks at the people who work
> their asses off to fix this stuff sure isn't a very good method to
> getting it fixed.
>
> Wow. What arrogance. IANAP either, probably have less experience than
> you in the field - but I sure now how to use a bit of elbow grease
> instead of spinning your wheels for everyone to hear to get things
> accomplished.
>

Jordan, That was me trying my best NOT to be rude, and understanding.
I've DONE an SRU patch, and I KNOW how much boring, hard work it is.

I WASN'T saying they're not doing any work, I'm saying that this
security bug slipped through the gaps.

If I COULD learn this language to fix it, I would, but I am a trainee
sysadmin / tech support guy, not a programmer, for a good reason. Take
note of my comment on my technical ability, please.

If you want to have a go at me, my email address is freely available.
Use it.

**** This is aimed as much at myself as anyone else. ****

Please remember the code of conduct, don't let this get heated:
http://www.ubuntu.com/community/conduct/

Jordan,

>Not that I know, but I don't think you understand the general process of using your (limited) resources as
>effectively as possible under a priority-based system for such an enormous project as Ubuntu.

You would be correct, the way in which Ubuntu seem to do things is beyond me.

>But you see my point, I hope.

I do, but you've totally missed my point.

>Be the one to push the changes you want to see. Remember the definition of Ubuntu.

I've been pushing Linux for a long time, indeed I first started writing Linux drivers in 1991 and was very excited when Linus finally turned out a hard disk driver. (!)

Ubuntu is *not* *my* project, I am merely a user, there are SO many issues with Ubuntu (mostly political), I really don't want to get involved any more than I am at the moment and reporting bugs is going to be my limit - I have other projects to work on where I have rather more control and can ensure .. correctness.

My point was not the lack of quality, the ability or time spent by sysadmins etc, it was that Ubuntu are misleading people by advertising one thing and offering up something else.

Giving "Linux" a bad name IS something that worries me.

It is not "my job" to find out who I should be emailing at Ubuntu and contacting them directly (although I've tried this to no avail in the dim and distant past). However, should enough people comment at the lower levels, my hope is that eventually it will filter up to people like yourself who do (or should?) have a little more sway with "da management".

So, in summary my complaint isn't really directed a "Ubuntu" the software, but rather "Ubuntu the organisation" making apparently misleading claims and potentially damaging the "Linux" name.

Note; making a "critical security flaw" a "low priority" is a bit of a contradiction in terms and something that's going to make the black-hats chuckle ... if you have time to produce a new release, why not *not* produce the release and fix all the holes in the current release first .. sorry, I said that already.

As the person who fixed the bug, and who is responsible for LTSPFS upstream, allow me to interject.

LTSPFS, or, for that matter, LTSP in the large, never had much of a security model. X was always launched without auth, LTSPFS had no security, etc. This is true for every version of LTSP from 1 to 4.2

When the original bug was filed, causing LTSPFS to gain some security, it required a fairly major rewrite of LTSP. Including going from the older Python LDM to the newer C one.

The massive changes to LTSP that occurred at that time and the resulting backport that were necessary were more than the limited pool of volunteer LTSP developers could handle at the time.

I think we need to be clear about what's "Ubuntu" and what's upstream. Ubuntu, the distro, reported a security flaw in LTSPFS. LTSP's response was to completely re-work LTSP, in essence, producing a whole new version. One that was almost impossible to backport into the distro. This is simply an outcropping of the policy of "The release in the distro should stay constant.".

Hope this, if nothing else, provides some historical background.

Cheers,
Scott

Your post;

>>27 Aug 2007
>>Fix is in my tree.
>>An mcookie is generated for the terminal, and set as an xprop during login.
>>Client must pass correct mcookie for connect to happen.

...

You will forgive me if I'm a little confused.
I know xprop, and I know roughly what X cookies are .. this doesn't sound like a "major" fix.

...

>One that was almost impossible to backport into the distro.

Really ?!

(Aug 2007, three unanswered questions about backporting ...)

>>27 Aug 2008
>>Ubuntu Edgy Eft is no longer supported, so a SRU will not be issued for this release. Marking Edgy as Won't Fix.

What happened to the posting a year earlier saying, "sorry, fix is too complicated so we won't be back porting it"?

Your previous postings and your historical update do seem to be rather "at odds".

We implemented a one-off fix for our customer, took a few hours but it went in. It probably wasn't something that the designers or Ubuntu would have approved of, but it worked. Had the posting at the time said "won'tfix" I might have been inclined to submit the code for others, seeing "fix is in my tree" I did not.

Given LTSP seems to be the cornerstone of EdUbuntu I'm a little gobsmacked that firstly nobody else spotted the issue and secondly it was deemed low priority.

Just as a general note, when you're running a LTS version of Ubuntu with 50 users on one server running LTSP in a live environment, the very LAST thing you want to do is to upgrade the OS to fix a bug. (not least given Ubuntu's track record on upgrades as already mentioned) So my point stands, if Ubuntu are not prepared to backport critical security updates to current LTS versions (as it was at the time) it doesn't seem "safe" to use in a commercial production environment.

Incidentally, one of the reasons this issue "rubs" is that I've "had" to upgrade to Intrepid to obtain fixes for stuff that isn't being backported to Hardy, unfortunately Intrepid currently has more holes than a sieve, random desktop logouts for no apparent reason and random screen lock-ups being two specific issues .. it seems like I'm forever chasing my tail just to get something that's stable.

Thanks Scott, I was hoping someone like you would chime in and put some
sense to it all. What you said was what I was trying to communicate with
'corner-case' since it has long been said to many that "LTSP-5 is the
current version that you should be using." (straight from #ltsp on
irc.freenode.net, not just Ubuntu people).

Cheers,
Jordan/Lns

Scott Balneaves wrote:
> As the person who fixed the bug, and who is responsible for LTSPFS
> upstream, allow me to interject.
>
> LTSPFS, or, for that matter, LTSP in the large, never had much of a
> security model. X was always launched without auth, LTSPFS had no
> security, etc. This is true for every version of LTSP from 1 to 4.2
>
> When the original bug was filed, causing LTSPFS to gain some security,
> it required a fairly major rewrite of LTSP. Including going from the
> older Python LDM to the newer C one.
>
> The massive changes to LTSP that occurred at that time and the resulting
> backport that were necessary were more than the limited pool of
> volunteer LTSP developers could handle at the time.
>
> I think we need to be clear about what's "Ubuntu" and what's upstream.
> Ubuntu, the distro, reported a security flaw in LTSPFS. LTSP's response
> was to completely re-work LTSP, in essence, producing a whole new
> version. One that was almost impossible to backport into the distro.
> This is simply an outcropping of the policy of "The release in the
> distro should stay constant.".
>
> Hope this, if nothing else, provides some historical background.
>
> Cheers,
> Scott
>
>

--
Jordan Erickson
Owner, Logical Networking Solutions
http://www.logicalnetworking.net
707-636-5678

Latest LNS Blogs - http://blogs.logicalnetworking.net

 Intel and HP team up to roll out Green PCs for the enterprise
 Mozilla Thunderbird Add-on "Signature Switch"
 Will "Windows 7" be another Mojave Experiment?

Gareth Bult wrote:
> Just as a general note, when you're running a LTS version of Ubuntu with
> 50 users on one server running LTSP in a live environment, the very LAST
> thing you want to do is to upgrade the OS to fix a bug. (not least given
> Ubuntu's track record on upgrades as already mentioned) So my point
> stands, if Ubuntu are not prepared to backport critical security updates
> to current LTS versions (as it was at the time) it doesn't seem "safe"
> to use in a commercial production environment.
>

> Incidentally, one of the reasons this issue "rubs" is that I've "had" to
> upgrade to Intrepid to obtain fixes for stuff that isn't being
> backported to Hardy, unfortunately Intrepid currently has more holes
> than a sieve, random desktop logouts for no apparent reason and random
> screen lock-ups being two specific issues .. it seems like I'm forever
> chasing my tail just to get something that's stable.
>
>

Again, I concur regarding this, and I don't "chase releases" either (not
since Gutsy). Again, though, the proper people aren't being notified
regarding this. It needs to go higher up in the chain if anybody expects
anything to happen. Otherwise, like I said, we're just spinning our
tires in a mostly empty parking lot, hoping someone in the neighboring
business park buildings will hear it. Not a very effective use of energy.

Gareth:

> You will forgive me if I'm a little confused.
> I know xprop, and I know roughly what X cookies are .. this doesn't sound like a "major" fix.

Well, for LTSPFS, it wasn't that major.

The problem, at the time, was that LDM, the display manager, had no method for us to call out any external process to set the xprop, or do any of the plumbing necessary to "make the magic happen", so the change to LTSPFS also required a rewite to LDM, and some other bits as well. At the time, it effectively became "a new version"

> Really ?!

Well, assuming "an infinite number of monkeys :)", we probably could have done it. The problem was, at that point we really only had 3 developers actively working on the code, and only 1 (myself) well versed in C. After all the work that had been done to rewrite LDM in C, it would have meant, in parallel, rewriting a Python version as well, and we were stretched a bit too thin.

> Given LTSP seems to be the cornerstone of EdUbuntu I'm a little gobsmacked that firstly nobody else spotted the issue > and secondly it was deemed low priority.

Since previous versions of LTSP had no security to speak of either, I can only suggest that this was considered a long standing problem, and "no different than the current state of affairs". None of us who work on LTSP are professional programmers who do It for a living, as LTSP isn't like Mozilla or Ubuntu: it generates no income, and is a completely volunteer, "for the love of it" organization. The fault that there was no security is purely upstreams.

> Incidentally, one of the reasons this issue "rubs" is that I've "had" to upgrade to Intrepid to obtain fixes for stuff that
> isn't being backported to Hardy, unfortunately Intrepid currently has more holes than a sieve, random desktop logouts
> for no apparent reason and random screen lock-ups being two specific issues .. it seems like I'm forever chasing my
> tail just to get something that's stable.

Are these LTSP related problems? If so, I'd be happy to help.

I'm away on Business 'till Thursday, but if you'd like to pop by either #ltsp or #edubuntu on freenode, I'm always more than happy to help debug problems. I'm sbalneav in the channels, both on freenode.

Cheers,
Scott