Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: GreyCloud <mist@xxxxxxxxxxx>
- Date: Sat, 20 May 2006 14:22:47 -0600
Daniel Johnson wrote:
"GreyCloud" <mist@xxxxxxxxxxx> wrote in message news:wtWdnfXoXO7kvvPZRVn-sw@xxxxxxxxxxxxxx
Daniel Johnson wrote:
I think I've made my case; but this is not related to it.
You haven't made any case.
First you better understand how the kernel gives out unique process ids first and also tied to the user id.
Process *ids* aren't tied to user ids; they are assigned sequentially.
True, but the supposed parent does have an id. And that id is traced back to init. If there isn't a traceable route, then that fork or thread will fail and not run.
Processes themselves are identifies by ids, and associated with
users, and much else.
That it is.
I
think the answer has not to do with how processes are
started, because I do not think that Timberwoof, or you,
have any answers.
Guffaw!!! Squirming away from the fundamentals of Unix
won't do you any good. It just is the way things are handled
in Unix.
You don't know how things are handled 'in Unix'; this is
evident because all technical details on this point that have
entered our discussion have done by from my hand.
Oh really? Where?
It is YOU that does not know what is going on under the hood of Unix.
Guffaw!!!
Your windows bias is strongly showing.
If you are a Mac advocate, it sure doesn't show.
[snip]
Everything coming into any UNIX box thru a browser is automatically set to read only.
This is not true. Try it yourself; download a text file
and then check to see if you can edit it.
But it is true.
It isn't. Try it.
I did. And I doubt that you are telling the truth here.
What facinating phrasing.
Yes. Even more fascinating is watching a wintroll dance.
If you tried it, were you able to edit the file you
downloaded?
I can download a file and I can edit that file.
But can a foreign program not tied to init do the same?
Nope.
Herein lies your own falsehood.
You should investigate more carefully about this before going on any further. You've been too closely tied to IE.
IE runs on the Mac.
Yeah, 5.5 version from a long time ago.
It's like wine. It's better if you let it age. :D
Guffaw!
And guess what... the kernel controls that process as well.
IE 5.5 does not equal IE 6.0. Matter of fact, IE 5.5 doesn't even resemble the M$ version at all. Where are the trojans for OS X?
There have been but a few, and those quite crude.
So crude that they can't get in. You are tying trojans to stupid users that don't know anything.
But no magic pixy dust in Mac OS X prevent those from
working.
Yeah sure. Why do I not get them then?
Seems like the majic pixy dust belongs to you alone.
[snip]
No; even if a browser were written that did mark all
downloads as read-only, it would do not good.
That's what you think.
It is quite correct, I assure you.
Proof?
And it does do a great deal of good. It prevents malware from executing and seeing that the downloaded object has no id or user id available, the kernel will not execute it.
No. Read-only files *do* have a user id and a group id.
(To see this, view them with "Get Info" in the Finder)
That's right... along with no execute bit set.
That's what read only means.
The file then gets assigned to be owned by the user.
How will it run?
By the stupid user to chmod +x that file and try to run it.
He deserves what he gets after that... but one important thing is that it will never affect system files. Unlike what happens to windows.
They *can* be executed. Indeed, it is very important that
this should be so.
Are you nuts?
< snipped nonsense >
[snip]
No; Mac acolytes seem terribly attached to this notion, but
it was never true. There have been exploitable bugs in IE,
but they didn't involve the user downloading things; they
were things that happened while browsing web pages.
(Which, if anything, is worse, but never mind that. :D )
Guffaw!! IE 6.0 has always executed stuff sent to it.
Sure: Javascript and so on. :D
And VBscript programs as well. Guffaw!!!!
Those are, however, not downloaded in the usual sense:
they are embedded in a web page.
And executed without you knowing it.
Don't know about IE 7.0, but that remains to be seen.
It works much the same way as IE 6.0.
What a horrible thing to do to the public.
Ever have your browser hijacked while surfing?
No.
It happens.
Same for OE.
As a rule, what happens to OE is that it hosts IE to render
HTML mail, and if IE is exploitable, OE is too.
It's a lot like Apple's Mail and WebKit, actually.
But actually not.
In what way is it different? It looks exactly the same
to me. WebKit=MSHTML; Safari=IE; Mail=OE.
Nothing more than an identification to the server.
One can change ids to servers using browswers of the likes of Konqueror.
Then the server will dish up the page. I've seen this all too often.
[snip]
Interestingly, Safari has some trouble here. To this day it
still installs downloaded dashboard widgets for you.
It does? I've never seen it do it.
I have. The security features (such as they are) now
appear to work, but the basic "auto install" feature remains.
Define "auto install"?
Try using Apple's widget directory web page. You won't
have to hand-install the widgets, if you are using Safari.
You have to select which one and these are on Apples web site.
Then you have to download that file. Then your intention to install that file is a double click. No different than issuing the various cli commands to unpack and install the program.
This does not actually run them, but it makes it all to easy
to do by accident.
Heh. I have to go to apple for widgets and select the ones I want.
Does "go to apple" mean "go to Apple's web page"?
Yes.
If so, it sounds like you *have* seem auto-installed
widgets. You did not have to drag the widget icon
into your Widgets directory, did you?
No. But my intention to install was a double click of the downloadable.
I've yet to see any security problems in this. Do You?
At least the "first run" warning actually works now.
Of course, Safari has also had a few bugs where downloaded
executables would run automatically, as well as the usual
buffer overflows and such.
Such as?
Here's one I dug up with a quick Google search on
"Safair Vulnerability":
http://www.heise.de/english/newsticker/news/69862
I don't have that turned on.
I used the NSA lock down procedure for OS X.
Programs like iChat I don't use and have purged my system of it.
But these are neglible compared to the damage I received using IE and OE.
[snpip]
The registry is much simpler: the keys that tell the OS
how to work with the app must be put there explicitly.
You must have an installer to do this, but the user must
explicitly *run* the installer. It won't be done for him.
There's no 'smart' auto-configuration, and no self-repair.
So? The registry is the one basket mechanism. If you drop the
basket all your eggs are broken.
There is, for once, truth in what you say. The lack of
an auto-repair facility is more secure, but less reliable.
One may argue that given Microsoft's vast market share,
and Apple's tiny one, they have both made the correct
choices- it is just that the best choice for an specialty OS
with few and more sophisticated users need not favor
security so much.
[snip]
They do have the user's uid and gid, of course. Most of
the recent Safari bugs are buffer overflows; injected code
will then run inside Safari with the user's uid and gid.
Do you know how a buffer overflow works?
Yes.
Good, then you will be hard pressed to find them in OS X.
There might be one, but it hasn't been discovered.
This type of code and bug is easily fixed.
Yes, once you know about it. But it is easily
written as well.
Of course, but then a good programmer that does it, will usually get fired for writing such poor code.
The best way to avoid it is to sacrifice performance
by using a safer, but slower, programming language-
something neither Microsoft nor Apple has been
willing to do too much.
In this I agree. C and C++ are pretty much bad in this. However, the latest Gnu C/C++ now warns you that some functions are dangerous to use and should be avoided.
I much prefer the older languages like Fortran that don't have that problem that I used to use under VMS.
Most of DECs os was written in BLISS that doesn't have this problem either. Of course vms is written in many different languages to take advantage of each languages features.
The auto-execute-downloaded-file bugs are Finder bugs,
and auto-exected files will be launched by the Finder, but
it's the same uid and gid.
What other would you expect?
I expect that you are wrong.
Why so? Just general principles?
Simple. Your principle beliefs are in error.
I've yet to have anything auto-execute on me from the internet.
Me neither.
I have under windows IE.
I went to a website a long time ago and all of a sudden the mouse was unresponsive... then this particular website wouldn't let me back up to a previous website nor shut off IE. I call this hijacking.
This is where the id/gid process permissions come into play.
Sure. But their behavior is simple and well documented.
And secure enough.
Now, how many $billions has M$ cost the IT industry?
Approx $2billion in damages.
--
Where are we going?
And why am I in this handbasket?
.
- Follow-Ups:
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Daniel Johnson
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- References:
- New Patch Fixes 43 Flaws In OS X, Many Serious
- From: John Slade
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Josh McKee
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Josh McKee
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Tim Murray
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Josh McKee
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: GreyCloud
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Daniel Johnson
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: GreyCloud
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Daniel Johnson
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: GreyCloud
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Daniel Johnson
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: sav
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Daniel Johnson
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: GreyCloud
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Daniel Johnson
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: GreyCloud
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Daniel Johnson
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: GreyCloud
- Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- From: Daniel Johnson
- New Patch Fixes 43 Flaws In OS X, Many Serious
- Prev by Date: Re: funny...
- Next by Date: Re: A cheapo Acer laptop matches Macbook Pro in benchmarks!
- Previous by thread: Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- Next by thread: Re: New Patch Fixes 43 Flaws In OS X, Many Serious
- Index(es):
Relevant Pages
|