Debian bug 737206 - rc shell uses insecurely /tmp

Debian bug 737206 - rc shell uses insecurely /tmp

[Stéphane Aulery]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Hello,

I make you pass an open bug report on the Debian bts about rc.
I do not know to whom I should speak. The code comes from 9base, who
just plan9port, etc. Here is the report [1]:

   Package: 9base
   Version: 1:6-6
   Severity: important
   Tags: security

   Murray McAllister from Red Hat Security Response Team discovered that rc
   creates temporary files in an insecure way:

   $ strace -o '| grep /tmp' ./test-heredoc
   open("/tmp/here217f.0000", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 5
   open("/tmp/here217f.0000", O_RDONLY|O_LARGEFILE) = 5
   moo
   unlink("/tmp/here217f.0000")            = 0

   As you can see, the filenames are easily predictable, and the O_EXCL
   flag is missing.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737206

Regards,

--
Stéphane Aulery

[-- Attachment #2: test-heredoc --]
[-- Type: text/plain, Size: 47 bytes --]

#!/usr/lib/plan9/bin/rc
cat << EOF
moo
EOF

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Wed, Dec 3, 2014 at 11:49 PM, Stéphane Aulery <saulery@free.fr> wrote:

> discovered that rc
>    creates temporary files in an insecure way:
>

rc was built for a system that made /tmp secure by not sharing it (it's
always private to a user and even sometimes to a set of processes).
That way not every app has to try to help sustain the pretence that a
shared /tmp can really be secured (+s bits, EXCL create, etc..)
Obviously the version for Unix will have to change its generation scheme to
fit in.

[-- Attachment #2: Type: text/html, Size: 919 bytes --]

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[Bruce Ellis]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

Don't these people have better things to do than finding non-bugs in
systems they don't understand?

brucee

On 5 December 2014 at 13:33, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On Wed, Dec 3, 2014 at 11:49 PM, Stéphane Aulery <saulery@free.fr> wrote:
>
>> discovered that rc
>>    creates temporary files in an insecure way:
>>
>
> rc was built for a system that made /tmp secure by not sharing it (it's
> always private to a user and even sometimes to a set of processes).
> That way not every app has to try to help sustain the pretence that a
> shared /tmp can really be secured (+s bits, EXCL create, etc..)
> Obviously the version for Unix will have to change its generation scheme
> to fit in.
>

[-- Attachment #2: Type: text/html, Size: 1441 bytes --]

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

+1 😄


> On Dec 4, 2014, at 7:08 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> 
> Don't these people have better things to do than finding non-bugs in systems they don't understand?
> 
> brucee
> 
>> On 5 December 2014 at 13:33, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>> 
>>> On Wed, Dec 3, 2014 at 11:49 PM, Stéphane Aulery <saulery@free.fr> wrote:
>>> discovered that rc
>>>    creates temporary files in an insecure way:
>> 
>> rc was built for a system that made /tmp secure by not sharing it (it's always private to a user and even sometimes to a set of processes).
>> That way not every app has to try to help sustain the pretence that a shared /tmp can really be secured (+s bits, EXCL create, etc..)
>> Obviously the version for Unix will have to change its generation scheme to fit in.
> 

[-- Attachment #2: Type: text/html, Size: 1770 bytes --]

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[Kurt H Maier]

Quoting Bruce Ellis <bruce.ellis@gmail.com>:

> Don't these people have better things to do than finding non-bugs in
> systems they don't understand?
>
> brucee

This bug is being reported against 9base, which is a port of stuff
to unix similar to (and based on) plan9port.

He is reporting it to 9fans and 9trouble because Debian people are
not very good at doing things correctly.   Fortunately he seems to
accidentally have sent his message to some folks who might care in
addition to the ones who don't.

khm

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[Bruce Ellis]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Well I hope he has fun fixing a sandwich. Your words  ... "because Debian
people are not very good at doing things correctly".

On 5 December 2014 at 15:14, Kurt H Maier <khm@sciops.net> wrote:

> Quoting Bruce Ellis <bruce.ellis@gmail.com>:
>
>  Don't these people have better things to do than finding non-bugs in
>> systems they don't understand?
>>
>> brucee
>>
>
> This bug is being reported against 9base, which is a port of stuff
> to unix similar to (and based on) plan9port.
>
> He is reporting it to 9fans and 9trouble because Debian people are
> not very good at doing things correctly.   Fortunately he seems to
> accidentally have sent his message to some folks who might care in
> addition to the ones who don't.
>
> khm
>
>
>

[-- Attachment #2: Type: text/html, Size: 1370 bytes --]

Re: Debian bug 737206 - rc shell uses insecurely /tmp

[anselm]

Hi there,

On 4 December 2014 at 00:49, Stéphane Aulery <saulery@free.fr> wrote:
> I make you pass an open bug report on the Debian bts about rc.
> I do not know to whom I should speak. The code comes from 9base, who
> just plan9port, etc. Here is the report [1]:
>
>    Package: 9base
>    Version: 1:6-6
>    Severity: important
>    Tags: security

thanks for passing this issue on. I intend to address this issue in
the upcoming 9base-7 release.

Out of curiosity, does anybody know if current p9p is still affected
by this? Presumablyit is just 9base-6, as it is based on a 4 year old
p9p pull...

BR,
Anselm

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[sl]

Aren't they talking about rc when running on their operating system?

sl

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[David L. Craig]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

On 14Dec04:2238-0500, sl@9front.org wrote:

> Aren't they talking about rc when running on their operating system?

Certainly.  It serves as a textbook example of inadequate
software porting due to insufficient understanding of the
differences between the source and target environments.
Once the defect in the port is revealed, it serves as a
textbook example of inadequate ported software support
that has to inquire of the source maintainers if the
misbehavior in the ported environment is also present in
the source environment (I am reluctant to suggest they
believed the responsibility of remediation lies with the
source maintainers).  Once again: Plan 9 is not UNIX--
porters in either direction, beware.
-- 
<not cent from sell>
May the LORD God bless you exceedingly abundantly!

Dave_Craig______________________________________________
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_________________

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

> Aren't they talking about rc when running on their operating system?


I'd still fix /tmp, myself. It does nothing but fester. Even the PDP-11 it
was a nuisance.
40 years on, you'd think someone would deal with it.

[-- Attachment #2: Type: text/html, Size: 470 bytes --]

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[lucio]

> I'd still fix /tmp, myself. It does nothing but fester. Even the PDP-11 it
> was a nuisance.
> 40 years on, you'd think someone would deal with it.

Are you being intentionally ambiguous, Charles?  /tmp/ in Unix (my
guess) or /tmp/ in Plan 9 (quantum forbid!) as Unix aficionados may
choose to interpret your comment?

You need personal namespaces for the former and, I have no doubt, too
much is at stake for those to be much of an option right now - mobile
phones notwithstanding (cf. Ubuntu Phone).

Lucio.


-------------------------------------------------------------------------------------
This email has been scanned by the MxScan Email Security System.
-------------------------------------------------------------------------------------

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Sat, Dec 6, 2014 at 5:22 AM, <lucio@proxima.alt.za> wrote:

> 40 years on, you'd think someone would deal with it.


The point I was trying to make is that it was realised early on (eg, when
time-sharing at universities)
that a shared /tmp was a problem. Hacks such as +s or special schemes for
allocating files don't really
address the problem.

Now look at that number: 40. Four decades. During that time there has been
any amount of foolish
crud added to this or that kernel, distribution ,graphics subsystem,
standards, ... but instead of fixing
it after 4 0 years, we get notes explaining that it's the application's
business, in this case the shell,
or perhaps the underlying library, to try to address "security issues"
instead of fixing it, once for all.
After 40 years (more than a generation).

[-- Attachment #2: Type: text/html, Size: 1377 bytes --]

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[erik quanstrom]

> Now look at that number: 40.  Four decades.  During that time there
> has been any amount of foolish crud added to this or that kernel,
> distribution ,graphics subsystem, standards, ...  but instead of
> fixing it after 4 0 years, we get notes explaining that it's the
> application's business, in this case the shell, or perhaps the
> underlying library, to try to address "security issues" instead of
> fixing it, once for all.  After 40 years (more than a generation).

+1.  this is really an important point.  think of all the mega person
years you could save by doing the simple, systemic things to make
the job of maintaining system easier.

- erik

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[Wes Kussmaul]

On 12/06/2014 01:41 PM, erik quanstrom wrote:
>>   instead of
>> fixing it, once for all.  After 40 years (more than a generation).
> +1.  this is really an important point.  think of all the mega person
> years you could save by doing the simple, systemic things to make
> the job of maintaining system easier.

Think of all the mega person years in... picking one example... the 
managed security services industry.

Mega *billable* person years...

Folks, as long as those who care about the integrity of the world's 
information infrastructure work at the direction of those who do not, 
nothing will get fixed.

-- 

Wes Kussmaul
The Authenticity Institute
738 Main Street
Waltham, MA 02451

office +1 781 790 1674
mobile +1 781 330 1881

“Try this fruit, and by the way if a bunch of people collectively calling themselves Arthur Andersen signs something it’s the same as if a person named Arthur Andersen signed it.”

	- The Serpent

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[lucio]

> +1.  this is really an important point.  think of all the mega person
> years you could save by doing the simple, systemic things to make
> the job of maintaining system easier.

You are missing an even more important issue here: imagine how much
beneficial impact such a radical break with tradition would have had
on the mindset of the community!  But we're dealing with conservatism
here and not with measurable improvements.

Also, and I am on Charles' side on this, _who_ should have done this?
Sun Microsystems, Microsoft?

And how do we know that it has not been done, but was rejected?  The
technology is not driven by need but, surprise, surprise, by greed.

And, most importantly, it is a complex blend of science and
engineering with no moral compass and plenty of money.  Is it
surprising that it fails to address problems without profitable
solutions?

My beef with Charles, by the way - and I must have been guilty of the
same sin as he - is not that he is mistaken, but that he formulated
his criticism in an ambiguous manner, where it is necessary that it
should be very clear which of two alternatives he is criticising.  I
simply wish there was less of that, specially on a mailing list where
English is not everyone's mother tongue.  Sometimes I can't resist the
temptation to bring this to everyone's attention.

No offence was intended and if some was taken, I apologize.

Lucio.

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[erik quanstrom]

> > +1.  this is really an important point.  think of all the mega person
> > years you could save by doing the simple, systemic things to make
> > the job of maintaining system easier.
>
> You are missing an even more important issue here: imagine how much
> beneficial impact such a radical break with tradition would have had
> on the mindset of the community!  But we're dealing with conservatism
> here and not with measurable improvements.
>
> Also, and I am on Charles' side on this, _who_ should have done this?
> Sun Microsystems, Microsoft?

conservatism is not the reason.  the reason is lack of clear thinking.
like the summit guys suggesting pipe1.

by the way, i set up an automounter for irix 3 and 4 way back when that
set up private temp directories, among other things.  it's even been done.

- erik

Re: [9fans] Debian bug 737206 - rc shell uses insecurely /tmp

[Bruce Ellis]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

As in "I have ties older than your /tmp".

On 7 December 2014 at 05:29, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On Sat, Dec 6, 2014 at 5:22 AM, <lucio@proxima.alt.za> wrote:
>
>> 40 years on, you'd think someone would deal with it.
>
>
> The point I was trying to make is that it was realised early on (eg, when
> time-sharing at universities)
> that a shared /tmp was a problem. Hacks such as +s or special schemes for
> allocating files don't really
> address the problem.
>
> Now look at that number: 40. Four decades. During that time there has been
> any amount of foolish
> crud added to this or that kernel, distribution ,graphics subsystem,
> standards, ... but instead of fixing
> it after 4 0 years, we get notes explaining that it's the application's
> business, in this case the shell,
> or perhaps the underlying library, to try to address "security issues"
> instead of fixing it, once for all.
> After 40 years (more than a generation).
>

[-- Attachment #2: Type: text/html, Size: 1833 bytes --]