DaleA@cup.portal.com (Dale M Arends) (06/07/89)
I heard from Datapak about the interaction between Printer Interface III and GK. According to them, they are storing the latest page format record in a CODE resource instead of a PREF (or other type of) resource. They are aware that this causes a problem but feel that what they are doing is "perfectly legal" and do not feel a need to change. Their recommendation was to have GateKeeper not reject when a DRVR modifies a CODE resource. My opinion is that it is a bogus "solution" and that doing so would nullify a large portion of GateKeeper's protection. I feel that they are wrong and let them know. If you agree, why dont you spread the word to the sites and maybe, if many complain to them, they will correct the problem. Dale ------- DaleA@cup.portal.com
dplatt@coherent.com (Dave Platt) (06/08/89)
In article <19190@cup.portal.com> DaleA@cup.portal.com (Dale M Arends) writes: > I heard from Datapak about the interaction between Printer Interface III > and GK. According to them, they are storing the latest page format record > in a CODE resource instead of a PREF (or other type of) resource. They > are aware that this causes a problem but feel that what they are doing is > "perfectly legal" and do not feel a need to change. Their recommendation > was to have GateKeeper not reject when a DRVR modifies a CODE resource. > > My opinion is that it is a bogus "solution" and that doing so would nullify > a large portion of GateKeeper's protection. I feel that they are wrong and > let them know. If you agree, why dont you spread the word to the sites and > maybe, if many complain to them, they will correct the problem. I agree that this driver is doing something that it shouldn't; every other printer driver I've ever used stores its configuration in a PDEF, or similar resource. I called this problem to DataPak's attention the day I received version 2.0 of their driver (a couple of months ago), and suggested that they switch to a more-standard method of storing their config info. They said they'd look into it; I'm sorry that they've decided against making the change. What they're doing is (technically) legal, but I consider it a nonstandard and rather-dubious design. It's a shame... I like their driver very much. Fortunately, the problem isn't as bad as you suspect. Printer Interface III stores its configuration information in its own DRVR resource (which does contain executable code), _not_ in a CODE resource. To date, I've not heard of any Mac viruses that spread via DRVR resources... those which infect applications, do so by modifying CODE resources. So... one can remove DRVR from the list of resource-types that GateKeeper protects, without opening the door to infection by viruses such as nVIR. I've been running in this mode for several months, without any problems; GateKeeper will still block infection by all known viruses. -- Dave Platt FIDONET: Dave Platt on 1:204/444 VOICE: (415) 493-8805 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
chrisj@ut-emx.UUCP (Chris Johnson) (06/08/89)
In article <19190@cup.portal.com> DaleA@cup.portal.com (Dale M Arends) writes: > I heard from Datapak about the interaction between Printer Interface III > and GK. According to them, they are storing the latest page format record > in a CODE resource instead of a PREF (or other type of) resource. They > are aware that this causes a problem but feel that what they are doing is > "perfectly legal" and do not feel a need to change. Their recommendation > was to have GateKeeper not reject when a DRVR modifies a CODE resource. In article <26073@coherent.com> dplatt@coherent.com (Dave Platt) writes: >I agree that this driver is doing something that it shouldn't; every >other printer driver I've ever used stores its configuration in a PDEF, >or similar resource. I called this problem to DataPak's attention the >day I received version 2.0 of their driver (a couple of months ago), and >suggested that they switch to a more-standard method of storing their >config info. They said they'd look into it; I'm sorry that they've >decided against making the change. What they're doing is (technically) >legal, but I consider it a nonstandard and rather-dubious design. It's >a shame... I like their driver very much. [some elaboration removed.] >So... one can remove DRVR from the list of resource-types that >GateKeeper protects, without opening the door to infection by viruses >such as nVIR. I've been running in this mode for several months, >without any problems; GateKeeper will still block infection by all >known viruses. A general comment on this topic for the consideration of DataPak & GK users: It's true that no known viruses can infect a DRVR resource, but the key word in this sentence is: "known". DataPak is, it seems, saying that the whims of their peculiar implementation should take precedence over the security of their users' Macs. I don't think this is a sensible or responsible attitude. Of course, GateKeeper is not perfect -- it cannot guarantee protection against every virus that might ever appear, but it provides the best protection available to a lot of Mac users. A company asserting that, for the sake of its one curious product, the level of protection that GateKeeper *does* pro- vide should be *reduced* seems, to me, guilty of an absurd conceit. Is it so much to ask of this company that it refrain from using executable resources for data storage? From what the first of these posters says, apparently the company feels that it *is indeed* too much for its customers to ask. I've said what I have to say. You be the judge. ----Chris (Johnson) ----Author of GateKeeper