DO> > How about if Machine Lock completely disables the usage of the shift> DO> key at startup?
DO> A Machine Lock extension (without a system patch) does not address the DO> other forms of attack I pointed out (re-posted below)
Disabling shift-key at startup is not a system patch. It's a 'preference' that can be adjusted by any application that's in the know.
DO> > I don't deny this Daniel, but Machine Lock is at least a start to> DO> prevent nosy people from taking a casual look at the server.
DO> As I recall, Machine Lock was created in response to Marcella/Glen's DO> request for security on an UNSECURE CPU. It cannot fulfill this DO> function.
In fact, it was designed to stop folks on the premises where our server is situated from snooping.
DO> > People who want to do serious damage etc can ALWAYS pull the plug--on > DO> any computer (without UPS!). If people are seriously converned about > DO> local access security, the phyiscal computer should be physically> DO> secured.
DO> People with basic knowledge of Macintosh startup procedures and DO> troubleshooting learn early-on about the method to bypass extensions.
As I said, shift-key startup can be disabled through an application (ie all extensions load).
DO> > DO> If file/directory permissions, access control lists, and in- DO> processencryption, were implemented INTO THE O/S, the system would be DO> MUCH MORESECURE from this type of an attack. Attempting to tack it on via DO> anapplication is a doomed proposition which further complicates other DO> OSoperations such as file recovery in the event of a crash.
DO> > Yes, but don't shout at me. > ;)
DO> Sorry, the caps are used for emphasis here.
Heh, I figured as much.
DO> > DO> The MacOS does NOT implement the concept of process ownership and> DO> is therefore susceptible to attacks designed to tap into or hi-jack> DO> running processes. Fortunately not many people currently know how to> do DO> this, but tools for learning about the processes running on a CPU> and DO> what data is involved in their operation do exist and can be used > to DO> break system security.
DO> > Errm, excuse me. Please explain what you mean. I get the feeling that > DO> what you have written here is just designed to scare people. From an > DO> experienced Macintosh programmer, 'tapping into' and 'hi-jacking' > DO> running process is absolute nonsense.
DO> I would beg to differ with you, from my viewpoint with experience in both DO> hardware design and test, as well as some software design. here is why:
DO> 1. With the tools available today, can you tell me that you can not DO> stop a running program (Hint: The Power PC is one of few processors that DO> you can actually get to stop ON an instruction without blowing through the DO> pipelines) and analyze the current machine state as well as view DO> internally used data?
Yes, but you can just as easily turn off the computer. Your info on the PowerPC being able to stop wherever is irrelevant here. Anyone with a debugger can get access to an application's data. However, who is silly enough to install a system debugger on a supposedly secure server mac?
DO> I was on a project over eight years ago to develop hardware that DO> essentially accomplished this. Its output was a disk file containing a DO> totally readible representation of the data entered by the user and the DO> program's processed output. Thus it could be mis-used to totally DO> circumvent CPU security. I can only imagine what could be done with DO> today's technology.
Maybe. However, if you can go to these lengths (get hardware in, access the motherboard, etc), you would surely also be ready to simply take the computer and fiddle with it at your leisure at home?
DO> 2. I have often seen the plain text contents of strings and DO> other program variables in memory locations I thought I should not see DO> when performing various tasks on the mac. Often I see the contents of DO> memory locations that contain data associated with other programs. I have DO> caught several programs doing this. Such poor handling of the memorycould DO> also be used to hack a system.
Yes, but only if a person has direct access and a debugger-style app. If they have direct access, then they will then be able to access such things anyway. What kind of strings have you 'though I should not see'??
DO> 3. Because there is poor memory protection, there is not much DO> to stop clever programmers with good tools from inserting additional code DO> into the system and altering the schedule of the calls so that internal DO> information regarding other system processes is available to their on a DO> periodic basis.
Memory protection isn't really so much of an issue here. Again, the key is that people AREN'T going to get to this stage (no shouting, just emphasis ;) because inherently with the Mac one doesn't need to go this far to discover secretive data. I realise that this is your key point, but I am trying to show that this nonsense about tapping into or hijacking processes isreally irrelecant.
DO> > Please don't take offense, but I feel you are exaggerating the problem> DO> somewhat.
DO> I do not feel that I am exaggerating the problem at all. I have a good DO> idea as to what is possible. It may be that the average PC Hack does not DO> know, or does not care to expend the time to learn. The major factors DO> that Macintosh systems rely upon for security are:
DO> 1. General lack of knowledge of the internal mechanisms of DO> the firmware, and operating system. Toolbox programming fosters this.
Toolbox programming isn't the only aspect of MacOS programming. It's what people who aren't in the know assume the mac is all about because that's what they hear about from time to time.
DO> 2. Misconceptions that Mac OS and other OS's share common DO> weaknesses in their security.
This I agree with.
DO> 3. Relatively steep learning curve and high cost involved to DO> become proficient in toolbox programming, when transitioning from older DO> methods.
I disagree--(toolbox==mac programming in general) the Mac is very easy to get to grips with, provided the learner can understand the event/object driven programming model. In addition, the inner workings of the system are fairly elementary, and may be mastered without much difficulty. Provided one is familiar with a debugger (eg MacsBugs), practically anything can be done.
Once again my key point is that all your program-hacking points aren't of relevance, because of the inherent insecurity of the Mac. People don't really need to go to all this trouble. Hence scaremongering.
Regards,
Jonathan Paisley, Sysop Highlander BBS Developer of MaxTF Utilities Modem: (+44) 141 561 7225 Internet: bbs.highlander.net.uk [TF/User and Telnet, both port 1474] WWW: http://www.highlander.net.uk/ mailto: jonathan_paisley@highlander.net.uk
