truesdel@ICS.UCI.EDU (Scott Truesdell) (02/18/90)
Mitch Kapor's new venture sounded like a neat hack. Then I read something in MacWorld, March, 1990, MacWorld News, page 119, right under Mitch's picture that chilled my blood. I quote: "AppleShare volumes also present a curious problem: [On Location] indexes don't respect AppleShare's security features, so you can't prevent users from finding text in folders they are not authorized to read. On Technology plans a fix for a later version." I administer a medium-size internetwork (8 servers) in an educational institution. Students have access to the networks. Faculty have access to the networks. Staff have access. The AppleShare security features ARE THERE FOR A REASON. We USE the security features. I now find myself in the extremely uncomfortable position of having to tell faculty and staff that any work stored on any server must now be considered available to the public. There is no concievable way to keep an individule from bringing in a copy of On Location, letting it build an index, then browse heretofor protected folders to their hearts content. Many faculty and staff have been keeping mild to very confidential material safely tucked away on various servers. Faculty keep exam materials, grades, and answers to the programming labs on the AppleShare servers. Gee, THANKS, Mitch. You have just stolen an important amount of functionality that I HAVE PAID FOR. You have added another layer of complexity to my job. You are denying me of something that is rightfully mine. HOW DARE YOU?!?!? Gee, THANKS, MacWorld. Thanks for blabbing this disasterous situation out in front of the whole world for anyone to see. Why don't you just publish the source code to a couple of viruses while you're at it!? I am NOT a happy camper tonight :-( --scott
ric@cs.arizona.edu (Ric Anderson) (02/18/90)
In article <17721.635313273@ics.uci.edu>, truesdel@ICS.UCI.EDU (Scott Truesdell) writes: > > Mitch Kapor's new venture sounded like a neat hack. > Then I read something in MacWorld, March, 1990, MacWorld News, page > 119, right under Mitch's picture that chilled my blood. I quote: > > "AppleShare volumes also present a curious problem: > [On Location] indexes don't respect AppleShare's > security features, so you can't prevent users from > finding text in folders they are not authorized to > read. On Technology plans a fix for a later version." > > I am NOT a happy camper tonight :-( > > --scott If this is true, the real problem is NOT "On Location" or MacWorld. The problem is that there exists a way for an ordinary application to bypass file server file protection. This would imply that anyone writing an application for a Mac can read AppleShare protected files. That's not a warm comforting thought, ESPECIALLY if there are students on one's AppleShare file server. Ric Ric Anderson Bitnet: Ric@Arizrvax Member of the Technical Staff Internet: ric@cs.arizona.edu University of Arizona UUCP: uunet!arizona!ric Department of Computer Science AT&T: (602) 621-4048 Gould-Simpson Room 721 Tucson, Arizona 85721 ---
minich@a.cs.okstate.edu (MINICH ROBERT JOHN) (02/18/90)
In article <17721.635313273@ics.uci.edu>, truesdel@ICS.UCI.EDU (Scott Truesdell) writes: >> >> Mitch Kapor's new venture sounded like a neat hack. >> Then I read something in MacWorld, March, 1990, MacWorld News, page >> 119, right under Mitch's picture that chilled my blood. I quote: >> >> "AppleShare volumes also present a curious problem: >> [On Location] indexes don't respect AppleShare's >> security features, so you can't prevent users from >> finding text in folders they are not authorized to >> read. On Technology plans a fix for a later version." >> >> I am NOT a happy camper tonight :-( >> --scott From article <18045@megaron.cs.arizona.edu>, by ric@cs.arizona.edu (Ric Anderson): > > If this is true, the real problem is NOT "On Location" or > MacWorld. The problem is that there exists a way for an > ordinary application to bypass file server file protection. Wow, wow, wow, hang on a minute, guys. I think something is being grossly misinterpreted, although the quoted article doesn't help us too much. To access an AppleShare volume from a network, you just HAVE to have the appropriate permissions to see the files. There are only a few possible ways I can think of to get around this, none of which are unstoppable. 1. On Location is used on the server, creating a handy index that everyone else on the network can see. Solution: don't put it on the server! If it isn't there, it can't create an index. Noone can access an index that isn't there! If your users who want to search for files on the server must use On Location, let them use it from their Mac and noone will see the index unless it is made available to everyone else. 2. On Location is used on the server, alowing anyone who uses the server as a workstation to see files they should not be able to see. Solution: don't let people use the server as a workstation. You can't do both at the same time, and I don't know why you'd be using AppleShare if you only used it part time. 3. On Location shares information between nodes on the net. (I really doubt this one. It's just too stupid to go to the effort and not have any protection.) In this case, I would think that if an individual didn't use On Location, HIS files would not be revealed to anyone since noone has permissions to see them. (Well, not unless they are _granted_ permissions :) I think the problem is most likely to be [1] since the [3] would need a lot of short-sighted work to program and not offer protection of private data and [2] is a trivial problem. Perhaps someone will fully clear this up, since I am NOT familiar with how On Location works. But I will gurantee this: a program can't access your private files from somewhere on a network other than a machine which is logged into the server WITH you logged on to the server, thus effectively granting any program you run to look at any files you can access. There is no way for a network program to just call up the server and walk through protected files without permission. A program running *ON* theserver is a different matter, but that shouldn't be a problem with security if you don't RUN the program on the actual server. Merely having a program stored on the server is not the same as having the server _running_ the program. PLEASE do not panic... Robert Minich minich@a.cs.okstate.edu NOTE: I have not used On Location nor do I know exactly how said program works but I do know about the routines to access an AppleShare file server. (They are documented in Inside Macintosh V if you must check for yourself.) I can't take any blame, but I'll be happy to take any credit you might offer. Have a nice day :-)
sharon@asylum.SF.CA.US (Sharon Fisher) (02/19/90)
In article <17721.635313273@ics.uci.edu> truesdel@ICS.UCI.EDU (Scott Truesdell) writes: > >Mitch Kapor's new venture sounded like a neat hack. >Then I read something in MacWorld, March, 1990, MacWorld News, page >119, right under Mitch's picture that chilled my blood. I quote: > > "AppleShare volumes also present a curious problem: > [On Location] indexes don't respect AppleShare's > security features, so you can't prevent users from > finding text in folders they are not authorized to > read. On Technology plans a fix for a later version." >Gee, THANKS, Mitch. You have just stolen an important amount of >functionality that I HAVE PAID FOR. You have added another layer of >complexity to my job. You are denying me of something that is >rightfully mine. HOW DARE YOU?!?!? > >Gee, THANKS, MacWorld. Thanks for blabbing this disasterous situation >out in front of the whole world for anyone to see. Why don't you just >publish the source code to a couple of viruses while you're at it!? If I read your posting correctly, you wouldn't even have known about the situation if MacWorld hadn't published it. Now you know. It's a pain, and I sympathize with you, but don't blame the press for alerting you to a dangerous situation. That's kind of what the press is for. Disclaimer: I'm a member of the press. :-)
tbutler@wpi.wpi.edu (Tim Butler) (02/19/90)
In article <17721.635313273@ics.uci.edu> truesdel@ICS.UCI.EDU (Scott Truesdell) writes: Mitch Kapor's new venture sounded like a neat hack. > Then I read something in MacWorld, March, 1990, MacWorld News, page > 119, right under Mitch's picture that chilled my blood. I quote: > > "AppleShare volumes also present a curious problem: > [On Location] indexes don't respect AppleShare's > security features, so you can't prevent users from > finding text in folders they are not authorized to > read. On Technology plans a fix for a later version." [remainder deleted] Isn't it interesting that an application must RESPECT Appleshare's security features? I think perhaps that instead of On Technology planning a fix, Apple should be planning a fix. If On Location drops this *feature* then many people may forget about it and therefore place themselves in a vulnerable position. Anyone who then had the older version would still be able to access protected volumes. gee, those car theives didn't respect my 'don't steal my car' signs! -tim Tim Butler (tbutler@wpi.wpi.edu) Teaching Assistant HL 103b ext.5424 Department of Mechanical Engineering Worcester Polytechnic Institute
kanefsky@umn-cs.cs.umn.edu (Steve Kanefsky) (02/19/90)
In article <8514@wpi.wpi.edu> tbutler@wpi.wpi.edu (Tim Butler) writes: >In article <17721.635313273@ics.uci.edu> truesdel@ICS.UCI.EDU (Scott Truesdell) writes: > > Mitch Kapor's new venture sounded like a neat hack. >> Then I read something in MacWorld, March, 1990, MacWorld News, page >> 119, right under Mitch's picture that chilled my blood. I quote: >> >> "AppleShare volumes also present a curious problem: >> [On Location] indexes don't respect AppleShare's >> security features, so you can't prevent users from >> finding text in folders they are not authorized to >> read. On Technology plans a fix for a later version." > > [remainder deleted] > >Isn't it interesting that an application must RESPECT Appleshare's security >features? I think perhaps that instead of On Technology planning a fix, Apple >should be planning a fix. If On Location drops this *feature* then many >people may forget about it and therefore place themselves in a vulnerable >position. Anyone who then had the older version would still be able to >access protected volumes. I don't believe that Appleshare's security has this terrible hole that everyone is claiming. Security which must be "respected" is no security at all. After having gone back and read the ad for On Location and the review in MacWorld, I think that the "curious problem" refers to the way On Location builds its index. Remember that On Location is constantly updating an index that takes up to 2% of the volume being indexed. My guess is that it is possible that On Location can store sensitive information in its index while someone is logged on to an AppleShare volume, which is then available to someone else logged on to the same volume with different access priviledges. If this is the case, then all one would have to do to maintain security would be not to use On Location while working on secure documents. That way, the contents of the document would never be indexed. Anyone using On Location later would not have access to that information. AppleShare volumes which haven't been indexed by On Location at all would have nothing to fear. Of course, everyone must be responsible for what INITs they are running. I don't suppose it would be hard to do On Location one better by writing an INIT that trapped save commands and always saved an extra copy of every document in a publicly accessible folder. -- Steve Kanefsky kanefsky@umn-cs.cs.umn.edu
meldal@ithink.Stanford.EDU (Sigurd Meldal) (02/19/90)
In article <17721.635313273@ics.uci.edu> truesdel@ICS.UCI.EDU (Scott Truesdell) writes: > >Mitch Kapor's new venture sounded like a neat hack. >Then I read something in MacWorld, March, 1990, MacWorld News, page >119, right under Mitch's picture that chilled my blood. I quote: > > "AppleShare volumes also present a curious problem: > [On Location] indexes don't respect AppleShare's > security features, so you can't prevent users from > finding text in folders they are not authorized to > read. On Technology plans a fix for a later version." > >Gee, THANKS, Mitch. You have just stolen an important amount of >functionality that I HAVE PAID FOR. You have added another layer of >complexity to my job. You are denying me of something that is >rightfully mine. HOW DARE YOU?!?!? If Kapor can do it, then others can also. One should always treat files on net servers as more-or-less publicly accessible. Do you really think none of your students is clever enough to figure this one out for herself? Particularly for a low-security world like Apple's. Material that you cannot afford to let the world know should be kept on floppies, or encrypted in some way. E.g. confidential letters can be kept on servers, if their becoming public is no more than a nuisance. Exams and similar material whose public availability would spell disaster should ALWAYS be kept off the net, be it UNIX or MacOS based. >Gee, THANKS, MacWorld. Thanks for blabbing this disasterous situation >out in front of the whole world for anyone to see. Why don't you just >publish the source code to a couple of viruses while you're at it!? The dissemination of information about security problems always poses a problem. By making the problem known you got the opportunity to take remedial steps. Would you be so sure that none of your students (or other unscrupulous users) would get to know it independently? >I am NOT a happy camper tonight :-( Understandable. -- Sigurd Meldal
alms@cambridge.apple.com (Andrew L. M. Shalit) (02/20/90)
In article <17721.635313273@ics.uci.edu> truesdel@ICS.UCI.EDU (Scott Truesdell) writes:
Gee, THANKS, MacWorld. Thanks for blabbing this disasterous situation
out in front of the whole world for anyone to see. Why don't you just
publish the source code to a couple of viruses while you're at it!?
Even better, why not blab it all over Usenet? (No, I don't read
MacWorld.)
-andrewmeuchen@grad2.cis.upenn.edu (Paul Eric Menchen) (02/20/90)
In article <18045@megaron.cs.arizona.edu> ric@cs.arizona.edu (Ric Anderson) writes: >In article <17721.635313273@ics.uci.edu>, truesdel@ICS.UCI.EDU (Scott Truesdell) writes: >> >> Mitch Kapor's new venture sounded like a neat hack. >> Then I read something in MacWorld, March, 1990, MacWorld News, page >> 119, right under Mitch's picture that chilled my blood. I quote: >> >> "AppleShare volumes also present a curious problem: >> [On Location] indexes don't respect AppleShare's >> security features, so you can't prevent users from >> finding text in folders they are not authorized to >> read. On Technology plans a fix for a later version." ... >This would imply that anyone writing an application for a >Mac can read AppleShare protected files. That's not a warm >comforting thought, ESPECIALLY if there are students on one's >AppleShare file server. Well thank you for that strong sense of trust. I did things like you are concerned about my freshman year of high school. I'd like to think that most of us on the net (particularly students) have a little more respect for privacy than you give us credit for. If I were to draw an equally bad hasty generalization based on your remarks, I sure hope there aren't any faculty or administrators on my AppleShare file server. Paul Eric Menchen meuchen@grad1.cis.upenn.edu
truesdel@ICS.UCI.EDU (Scott Truesdell) (02/20/90)
------- Forwarded Message
Received: from gateway.qm.apple.com by goofy.apple.com (5.51/25-eef)
id AA02895; Mon, 19 Feb 90 12:54:01 PST
for truesdel@ics.uci.edu
Message-Id: <9002192054.AA02895@internal.apple.com>
Date: 19 Feb 90 12:03:39
From: Tom Dowdy <Tom_Dowdy.SNARKMAIL_A_K@gateway.qm.apple.COM>
Subject: AppleShare and On Location
To: truesdel@ICS.UCI.EDU
Snausages! From the office of Tom Dowdy
Regarding: AppleShare and On Location
Okay.
I just got a call back from one of the main AFP folks. There is *no* way that
On Location could be getting around the AppleShare file mechanisms, and your
server is perfectly save. AFP has no "block read" type primative, so there
isn't any way that a program can get to a file they aren't allowed to have.
As I stated before, if the admin runs an On Location index on the server and
then places that index in a public place, or if a user does the same for those
files s/he has access to, this can cause a problem. The answer to this is
"don't do that" and you shouldn't have any problem.
You can post this to the net if you like, or I will.
Just wanted to get back to you as soon as possible with a more concrete answer.
Tom Dowdy Internet: dowdy@apple.COM
Apple Computer MS:81EQ UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
20525 Mariani Ave AppleLink: DOWDY1
Cupertino, CA 95014
"The 'Ooh-Ah' Bird is so called because it lays square eggs."
------- End of Forwarded Message
Thank you, Tom. This looks like a more manageable problem now.
--scottlsr@Apple.COM (Larry Rosenstein) (02/21/90)
In article <17721.635313273@ics.uci.edu> truesdel@ICS.UCI.EDU (Scott Truesdell) writes: > "AppleShare volumes also present a curious problem: > [On Location] indexes don't respect AppleShare's > security features, so you can't prevent users from > finding text in folders they are not authorized to > read. On Technology plans a fix for a later version." The key word here is "indexes". On Location doesn't require that the actual documents be online to perform a search. All the data needed to do the search is in the index file. So if you provide people with an index of your hard disk (or private AppleShare folders) then they will be able to find all documents containing certain words. They still won't be able to view the contents of the documents, since the index only contains a signature of the document and not the actual contents. What the comment above means is that On Location doen't keep track of whether the user doing the search is allowed to access the found document. (I don't think that's its job either.) This could be considered a security problem if the title of a document (or whatever else On Location saves) is sensitive. If you care about people doing this kind of search, then you simply don't make the index available. The only potential problem is if On Location maintains a global index of a server by accumulating changes made by all users. I haven't played with it myself, by it seems that this would be only one way of using the program, and something that is easily avoidable. > to the networks. Staff have access. The AppleShare security features > ARE THERE FOR A REASON. We USE the security features. This does not represent a sercurity problem. The server manages all requests for data, and won't allow unauthorized users to access private files. It doesn't matter what software you run on the client machines. The worst security problems are still going to be someone gaining physical access to the the server or someone using a client machine that has the server mounted. In theory, someone can listen in on the network and grab packets, but that requires some technical knowledge. > considered available to the public. There is no concievable way to keep > an individule from bringing in a copy of On Location, letting it build > an index, then browse heretofor protected folders to their hearts This scenario isn't possible. The only way On Location can index private documents is if the indexing is done by a legitimate user. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
truesdel@ics.uci.edu (Scott Truesdell) (02/21/90)
minich@a.cs.okstate.edu (MINICH ROBERT JOHN) writes: >[...] There are only a few possible ways I can think of >to get around this, none of which are unstoppable. >1. On Location is used on the server, creating a handy index that everyone else >on the network can see. Solution: don't put it on the server! If it isn't there, >it can't create an index. Noone can access an index that isn't there! If your >users who want to search for files on the server must use On Location, let >them use it from their Mac and noone will see the index unless it is made >available to everyone else. [other ideas deleted] > I think the problem is most likely to be [1] since the [3] would need a lot of >short-sighted work to program and not offer protection of private data and [2] >is a trivial problem. I believe this now, too. Tom Dowdy <dowdy@apple.com> did some looking into the matter and came up with pretty much this same conclusion. Since I, as administrator, am the only one with write priveledges to the root directory of our servers, I can pretty much keep this from happening. If others build indexes which access protected information of their own, then pass these indexes on to friends, it's only THEIR files they are compromising. So all I really need to do is warn people about this unlikely set of circumstances. The whole story isn't out yet, but it's looking better than the MacWorld article caused me to believe. --scott Have a day :-| -- Scott Truesdell
truesdel@ics.uci.edu (Scott Truesdell) (02/21/90)
alms@cambridge.apple.com (Andrew L. M. Shalit) writes: >In article <17721.635313273@ics.uci.edu> truesdel@ICS.UCI.EDU (Scott Truesdell) writes: > Gee, THANKS, MacWorld. Thanks for blabbing this disasterous situation > out in front of the whole world for anyone to see. >Even better, why not blab it all over Usenet? (No, I don't read >MacWorld.) Because people here, I believe, represent a special subset of Mac users, a cut above average both technically and ethically. The damage (if indeed it WAS damage, already being a done deed, I wanted the opinion of folk I respected. On the other hand, the jab at MacWORLD was misplaced because, I think we all agree, ignorance of a security hole is NO security. At least not for long. --scott -- Scott Truesdell
nilesinc@well.sf.ca.us (Avi Rappoport) (02/22/90)
I sent Mitch a copy of the original posting, and this is his reply: "You cannot install or run On Location on an Appleshare server. To index an Appleshare volume, mount the volume on the Macintosh, then index normally, storing the index locally. To allow sharing of this index, copy it to an On Location indexes folder in the root directory of the remote volume. The ahred copy cannot be auto-updated. To update this index you must reindex a local copy and copy the updated index back to the remote volume" -- On Location manual p. 19 Done in this fashion, On Location indexes do respect all privileges. That is, it won't index any files in folders the user doesn't have privileges to. If someone with privileges distributes an index, it will find files by name or by text that are in privileged folders. Even so, it will not let those without privileges view the files. So we do a pretty good job. I don't know how Mac News screwed this up, but it's unfortunate and we will ask them to run a correction. In the meantime, I'd respectfully ask you to post an update. Mitch Kapor mkapor@well.sf.ca.us 617 225-2345 (This was sent to truesdale@ICS.UCI.EDU Now if I could only figure out how to post this to the USENET. You have my permission to post it. I'm a total USENET novice, so I think I'll pass. So I have. Please send replies directly to him, as I'm no good at this mail stuff! Avi -- -- Help me justify my online bills: ask me EndNote questions, please! -- Avi Rappoport 2000 Hearst, Berkeley, CA 94709 nilesinc@well.sf.ca.us, 415-655-6666 Niles.Assoc on AppleLink fax: 415-649-8179
spencer@eecs.umich.edu (Spencer W. Thomas) (03/09/90)
I probably shouldn't get into this discussion (but I can't resist :-). From my understanding of the way that On Location works, my guess is that it allows you to know 1. The existence of files you can't see, and 2. That those files contain certain strings, but that it does not allow you to actually get at those files. Of course, (2) means you can, with infinite time and patience, eventually deduce the contents of the files. Think about how On Location works: it has 2 parts, a "foreground" piece that you call up and ask to find files containing a particular string, and a "background" piece that keeps the index database up to date. For servers (which is where the problem lies), the background piece runs on the server and therefore has access to all the files. So, all the files end up in the index. The foreground piece runs on your computer, and has access to the index, but not to all the files. To fix this, they have to check the access restrictions when you search the index. This could be done either by trying to access file that the search finds (requires no smarts in the file scanner), or by including information in the index about access rights (requires lotsa smarts in the scanner and a change to the index structure). A third option would be to restrict the set of files the scanner (background piece) is allowed to look at. So, while there is some violation of the access rights, it is not a total bypass, and does not indicate any weakness in the AppleShare access control software. -- =Spencer (spencer@eecs.umich.edu)
lsr@Apple.COM (Larry Rosenstein) (03/09/90)
In article <SPENCER.90Mar8140604@spline.eecs.umich.edu> spencer@eecs.umich.edu (Spencer W. Thomas) writes: > To fix this, they have to check the access restrictions when you > search the index. This could be done either by trying to access file > that the search finds (requires no smarts in the file scanner), or by > including information in the index about access rights (requires lotsa > smarts in the scanner and a change to the index structure). You wouldn't want to store access rights info in the index, because access rights change, and you also wouldn't want to depend on the current access privileges scheme. The idea of trying to access the file is a good one. You could also have an option to store the index on a per-folder basis. This would slow down searches, but guarantee complete security. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
truesdel@ics.uci.edu (Scott Truesdell) (03/13/90)
sharon@asylum.SF.CA.US (Sharon Fisher) writes: [ my complaint about On Location vs AppleShare priveledges ] [ my complaint that MacWorld's exposing of the "hole" was inappropriate ] >If I read your posting correctly, you wouldn't even have known about >the situation if MacWorld hadn't published it. Now you know. It's a >pain, and I sympathize with you, but don't blame the press for >alerting you to a dangerous situation. That's kind of what the press >is for. >Disclaimer: I'm a member of the press. :-) After having the facts 'splained to me by several people very knowledgable on the topic (including Mitch Kapor himself, thanks for the responce, Mitch!) I have come to retract my complaint and apologize to all parties involved. Please don't anyone sue me! :-( --scott -- Scott Truesdell