Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Apple Businesses

Apple Data Security Framework 77

Posted by michael from the polish-it-till-it-shines dept.
rschroeder writes: "Apple has opened their Common Data Security Architecture framework, which "contains an expandable set of cryptographic algorithms to perform code signing and encryption operations while maintaining the security of the cryptographic keys." Lots of good info in addition to the code."
This discussion has been archived. No new comments can be posted.

Apple Data Security Framework More

Apple Data Security Framework

Comments Filter:

  • Re:OpenSSL? (Score:1)

    by Anonymous Coward
    MacOS X has OpenSSL out of the box.

  • Re:Is this even a valid observation? (Score:1)

    by Anonymous Coward
    Microsoft has sold all of their stock - after the holding time they agreed on with Apple elapsed. Micro$oft gave Apple $170 million. Apple had/has over $4 BILLION in the bank... it was strictly a marketing ploy to give analysts confidence in the company's viability "If Micro$oft gave them money they must be OK... now I don't have to do any research!!" (not that analysts do actual reasearch anyway...)

  • Re:Thanks Apple (Score:1)

    by Anonymous Coward
    Won't happen. The price Apple would pay for doing that would be tremendous. Look at all the negative media talk that come about with MacOS X at it's introduction. Much of it is speculation and concerned claims that lack any concrete evidence. And this trouble was about a product that they adapted to run on their OWN hardware, hardware which they designed and internally documented.

    Now imagine the heat they would get with a GUI to run on other OSs. You'd have the Linux camp crying bloody hell because it's not free and how superior KDE and Gnome are. You'd hear people blame about how insecure it was because it was closed, even if it wasn't insecure. You'd hear people complain about how the GUI contributed to a security hole, even theough the underlying security hole was due to that other OS.

    Apple would hear about all the "incompatibilities" the GUI introduced. About how they couldn't "win in their own market on their own hardware" and had to "adopt" another market to survive.

    If Apple went to try some quality control and made an agreement with an x86 hardware manufacturer, say AMD, Athlon, and Micron Memory, you'd get folks schreaking about how Apple "tied" products together, where limiting their hardware "choices".

    And if they didn't "bundle" with hardware, the tech support issues they would have to deal with would be tremendous.

    There is NO WAY IN HELL Apple is releasing this GUI for general mass consumption on other generic hardware unless they have a direct tie into the underlying OS and hardware, or with huge disclaimers--someone gets it to work, Apple doesn't support it. So yes, they could port it to x86, but they'll do it on their terms, not on the consumers. I don't like that decision, but I certainly understand it, given what I've read on /. and in the media since MacOS X's release.

    The negative talk would hurt their bottom line on sales on their own proprietary hardware. Meanwhile, they would be losing money from the increased support. They'd have to charge upwards of $200 to cover this, and then the "bloody hell" cries would start and the cycle would begin again.

    Not going to happen.

  • Re:Intel CDSA (Score:1)

    by Anonymous Coward
    Yes, Intel developed the first version of the CDSA standard -- which was horribly broken. For CDSA 2, they brought in people from other companies, such as Apple, to help design an open standard. As a result, a much better specification was obtained.

    Yes, Intel has its own implementation but, if you've looked at it, you'll know that it has various issues and does not fully implement the spec. Apple's implementation was developed completely in-house and is not a port.

    Also, from what I hear, the Apple people are quite highly regarded by their peers at CDSA meetings...in fact, the Intel folk often go to them to get questions answered about the spec and the best way to implement it.

  • Re:No, Darwin isn't MacOS X lite (Score:1)

    by Anonymous Coward
    Well, Darwin builds on x86, and rumor has it that Apple engineers do parallel builds of the MacOS X code (minus the Carbon and Classic stuff that is Mac-hardware/PPC specific) in order to make sure that the portability that they inherited from NEXTSTEP doesn't get accidentally broken. It's not because Apple plans to ship on x86, but so that their core OS is portable so that in the future they have the option of switching chips if Motorolla/IBM keep slacking off on performance.

    Remember, NEXTSTEP runs on SPARC, HP PA-RISC, x86, PPC, 680x0, etc., so the core OS is already proven to be highly portable.

  • Apple and CDSA (Score:2)

    by Anonymous Coward
    CDSA is more than just an equivalent of openSSL...
    CDSA is a standard that was established by the open groups, a number of corporations are working on CDSA products, it does provide a large range of services other than providing a common API for cryptographic services, trust policy, certificate library and so on.
    While it offers a standard way of securely communicating data, it also offers a common way to establish policies and the many things. it was meant to be a complete solution for security, especially for e-commerce.

    It's nice to see an implementation openly available, if no one uses it it will still be easier to ensure interoperability with MacOS X...
    Also it brings some publicity to CDSA, which is not bad.

    In my opinion, it's a good thing.

  • Re:Good first step (Score:2)

    by Anonymous Coward
    Unfortunately, the attacks on apple not being security conscious, much like them not contributing back to the community, are totally unfounded by people who have watched what the company has been doing for the past year.

    The reality is, the Apple is not secure concerns are media spins by folks who are looking for a problem to write about. Not finding it, they write about "concerns" and play on the ignorant OS advocates and trollers, who respond and draw everyone else into the mix.

    It's been like this for ages. Look at the /. articles. There's one that Apple is not being security conscious. Then there's an Ask Slashdot which accuses Apple of too many upgrades. Now this, where Apple has simply adapted technology to fit their machines--it's doubly played as if Apple invented it (they make no such claim) and is trying to take credit for it, and that Apple is upping security, as if Apple wasn't secure in the first place.

    Sorry, but there have been MORE exploits for Linux than MacOS X from the time MacOS X has been released. Worse, Linux has been around awhile, while MacOS X, being the new, unproven OS, should have been littered with holes. The opposite proves true, but you won't have people in the media or other OS advocates pointing that out.

  • Intel CDSA (Score:3)

    by Anonymous Coward on Thursday May 24, 2001 @07:33AM (#201047)
    Ummm... who cares about Apple? CDSA was developed by Intel. Intel is responsible for the bulk of CDSA. Intel built the code with portability in mind. That's why Apple was able to port it. http://developer.intel.com/ial/security/ http://developer.intel.com/ial/security/press.htm Intel released the source code in 2000: http://developer.intel.com/pressroom/archive/relea ses/in092500.htm
  • Microsoft is a minority shareholder
    Not even that. MS holds nonvoting stock.

  • For the last few versions, the Mac OS has been loading it's "ROMs" off disk early in the boot process. Look in the system folder for a file named Mac OS ROM.

    Of course, you're probably still right but about some other bit of hardware. Macs still have NVRAM, after all.

  • Yes, that is true. The Mac OS ROM is not actually a ROM anymore ,but is a file. This file, however, is still Apple's protected IP.

    In order for clones to pop up, Apple would have to license the use of this ROM file, which as mentioned in other comments, they will not do!

  • Re:OpenSSL? (Score:3)

    by awa ( 4952 ) <slash@delhelsa.com> on Thursday May 24, 2001 @07:36AM (#201051) Homepage
    Short answer: No.

    Longer answer: It's a security framework with hooks to a lot of things. If you'd read at least the introduction you'd have seen that it does, indeed, contain support for SSL, PGP and many other standard security/encryption/ham-and-cheese-sandwich technologies. Actually it's the MacOS X implementation of the OpenGroup standard. I do not know (did not find information more like it), however, if they _did_ implement the whole schmiel.

    Longer longer answer: read the OpenGroup documentation. Download the code. Read the code. Come back and tell us about it.
  • A cool thing about the CDSA is that you can replace any part you don't like. So, if you feel the NSA has compromised it, you can replace the crypto portions with your own provider based on OpenSSL.

    -Dave
  • > while maintaining the security of the cryptographic keys

    That would make a change.

    http://lwn.net/1999/1202/security.php3
    http://www.cs.auckland.ac.nz/~pgut001/pubs/pwl.t xt
    http://www.cs.auckland.ac.nz/~pgut001/pubs/break ms .txt
    http://www.cs.auckland.ac.nz/~pgut001/pubs/break ms 2.txt
    http://www.cs.auckland.ac.nz/~pgut001/pubs/break ms 3.txt

    --
  • First off the URL is http://msdn.microsoft.com/library/psdk/crypto/cryp toref1_0lwh.htm [microsoft.com], yours was mangled.

    Secondly I don't see any references as to the encryption used - it's a MS-specific blackbox as far as I can tell. Considering MS's shaky history of security implementations & the general problem of closed-source encryption this isn't particularly comperable to Apple's Open Source implementation of an outside published standard written by broad coalition of interested users.

    Finally what uses this? Win2k has literally thousands of API's, some excellent, some half-baked, some simply broken or braindead, many overlapping or redundant. Having an API is one thing, using it or getting it used is another, particularly in the archeology that is Win2k.

    Under MacOS 9 & 10 the Keychain is availiable from within the Finder, the Chooser, it's more modern implementation the Network Browser, the en/de-cryption applets, MS's Internet Explorer, most FTP clients including Interarchie & Fetch plus numerous other applications.

  • Some Background (Score:5)

    by maggard ( 5579 ) <michael@michaelmaggard.com> on Thursday May 24, 2001 @07:57AM (#201055) Homepage Journal
    First of all it needs to be pointed out Apple has been supporting encryption in their products for several years now.

    One of the features of MacOS 9 [apple.com] has been the ability to encrypt [apple.com] any file via a set of system-level services. A second feature has been the ability to use a "Keychain [apple.com]" service where passwords & other information can be securely stored & automatically retrieved by authorized applications. A third feature has been the ability to use a Voiceprint [apple.com] as a password.

    Here are a number of examples of how these features can be used:

    1. Macs running MacOS 9 and greater support Multiple Users [apple.com]. Thus folks can (or must) log in in order to access their materials. This login can be accomplished via typed password or Voiceprint [apple.com]. Macs with access to an appropriate server can store individual preferences on the server and these can used applied from client Macs as the user logs in.

    2. In order to encrypt or decrypt a file under MacOS 9 and greater on need simply drag-and-drop the file/folder/drive to the encryption application [apple.com]. This service can also be called from within any application utilizing the cryptographic API's.

    3. Utilizing the "Keychain [apple.com]" any program can store or retrieve settings, passwords and other secured bits of information. Thus instead of saving one's web-account passwords in an easily read text file they're stored encrypted in a file where explicit authorization must be given for access. The same for the other various servers one might utilize regularly or occasionally - their login information and passwords can be stored under a single master-password and applied at need.
    Now, lots of folks are going to start reading this and trying to imagine lots of ways they could break this, the possible downsides, etc. Yes, it's not completely foolproof. On the other hand it's a lot better then many other OS's offer, particularly when you realize it's widely supported throughout the OS and by many (most?) applications. Furthermore it seems fairly well thought out and after being out in the field a bit it seems to be working well.

    It's good to see Apple is finally documenting the same hooks in MacOS X. Presumably by completely opening the material a better evaluation of the processes can be made and improvements implemented by third parties. Furthermore since it's a standard promulgated by a number of companies all in the security field this has a good chance of being implemented in a wide range of products.

    It would also be great if other OS development folks could take this code and use it to compare/contrast their own efforts in this direction and use them to improve themselves, possibly even work towards adopting some common material where the specs are vague.

    Finally, before going and making wild-assed assumptions based on how you assume this stuff is implemented or blue-skying on it's possible flaws howzabout investing the 10 minutes and actually getting the facts first, not wasting all of the rest of ours time? This is all Open Source and it's well documented so it's not up to everyone else to teach you: Go read it for yourself.

  • Darwn is the base of MacOS X. Yes it's OpenSource. Yes it's freely avialable, Apple even hosts the servers & has engineers assigned to porting it to non-Apple platforms (to wit the x86.)

    That said there's a long distance between Darwin & MacOS X. Carbon, Quartz, Aqua, QuickTime, Classic - all are critical parts of MacOS X that aren't in Darwin. Without them Darwin is an interesting BSD variant with a Mach-based kernel, reworked IO & some nifty OO & "Frameworks" support and innovative configuration-files-settable-via-XML technology.

    That doesn't a clone make. Indeed it's debatable if Apple could themselves easily make a clone-able Mac at this point. So much of MacOS X (not Darwin) is PPC-specific and relies so heavily on Apple hardware implementations it might not be easily possible.

    Sure Next was ported many times & MacOS X has inherited much of that flexibility but since then there's been massive rewrites. It's likely that most of everything above Darwin might require a lot of work now move to another architecture or even motherboard design, there appear to be lots of assumptions made in the design.

    Sure there are always rumors of MacOS X running on x86/Alpha/etc. chips and there was a Rhapsody release that was cross-platform as well as stories of a beta MacOS 8 runnable on an IBM RS6000 but at this point it seems unlikely that the MacOS X now out there could be easily moved to either an Intel-standard motherboard architecture (BIOS/ Northbridge/Southbridge etc.) or to another workstation architecture using OpenFirmware etc.

    Possible: Yes.
    Easily Achieved: No
    Possible by someone other then Apple? No

    Darwin does not MacOS X make.

  • Could you please post some more information about this? I'd appreciate some specific instances of the coding assumptions you're talking about.

    --
  • For the last few versions, the Mac OS has been loading it's "ROMs" off disk early in the boot process. Look in the system folder for a file named Mac OS ROM.

    Yes, but there's still a boot ROM on the Macs. The ROM-in-RAM does load a "ROM" from a file on disk, but the Boot ROM (basically a BIOS) does quite a bit at startup. Here's info from the original iMac's developer notes:

    "The Boot ROM contains the code needed to start up the computer, initialize and examine the hardware, provide a device tree to describe the hardware, provide hardware access services (RTAS), and control to the OS. The Boot ROM can be grouped into the following major pieces. "

    Granted, this doesn't contain a significant portion of the OS, like the ROMs used to, but it's pretty key.

    -jon

  • No, there's more than OpenFirmware there; read the tech notes on the New World architecture. For example, the Ethernet driver is in the ROM, so Macs can be booted over the network (single System Folder on a server for a roomful of iMacs).

    -jon

  • Re:Thanks Apple (Score:3)

    by TWR ( 16835 ) on Thursday May 24, 2001 @08:15AM (#201060)
    . I'd personally like to see Apple take the initiative to install the operating system in a very secure state.

    Uh, it is. By default, Mac OS X ships with Mac file sharing off, FTP off, Apache off, and ssh off. Telnet is disabled in all versions since 10.0.1. If you want to turn them on, it's just a checkbox, but 99% of all Mac users won't turn on any of them except for Mac file sharing, which should be pretty safe; I don't know of any AppleTalk exploits.

    -jon

  • Re:Wow... more more more... (Score:3)

    by TWR ( 16835 ) on Thursday May 24, 2001 @08:24AM (#201061)
    Darwin makes Mac cloning possible, at least for small operators.

    No, it doesn't. Darwin alone isn't much more than a BSD variant, and I'd be pretty surprised if Apple isn't using the copyrighted ROMs on every Mac's motherboard as some sort of dongle for the higher-level Mac OS X functionality. You couldn't copy those ROMs without Apple's permission and that will happen over Steve's cold, dead body.

    Whether or not Apple could survive under a licensing system is a different debate. But I doubt that it'd be possible technically without Apple's blessing.

    -jon

  • Xinet (available for Solaris/SPARC and Irix) does use encrypted AFP passwords, and otherwise does an excellent job as a Unix AFP server. Helios, on the other hand, uses cleartext passwords. Xinet costs a bit of money, but might well be worth it.
  • Following the links to the Open Group and the Open Group Publications on the Web [opengroup.org] terms and conditions, I see:

    "2.You are permitted to read the HTML and PDF versions of Open Group publications using your HTML browser/Acrobat software and to download them for your own personal use provided you have given your name and email address for each publication requested. However, you are NOT permitted to amend, copy, reprint, offer for sale, or otherwise re-use material from these documents without explicit permission from The Open Group.

    I assume "otherwise re-use material" would include actually implementing the specification.

  • Funny thing. I clicked to download the code, server authentication box came up. I entered nothing and clicked ok. Let me right through :) I wonder if they are implementing their own procedures and standards. rb

  • Re:OpenSSL? (Score:3)

    by MochaMan ( 30021 ) on Thursday May 24, 2001 @08:27AM (#201065) Homepage
    Is the the MacOSX equivalent of OpenSSL?

    No. This is an extensible architecture that allows you to add modules for a ton of algorithms. Think of it more as a pluggable architecture something like Java's JCE.

    I'd assumed that OpenSSL would work on MacOSX, given all the spiel about it being Unix based.

    Mac OS X ships with TCPWrappers, OpenSSL and OpenSSH installed by default since version 10.0.1. There's a GUI interface available in the System Preferences panel to turn it on and off (if you're an administrator - ie. are in the wheel group).

  • CDSA specification... (Score:3)

    by victim ( 30647 ) on Thursday May 24, 2001 @07:37AM (#201066)
    For those of you wondering what a CDSA might really be, you can read all about it here [opengroup.org] at the opengroup.

    Good stuff.
  • You could do what I do - use Nifty Telnet SSH [lysator.liu.se] to scp files around, tarring them from the shell if necessary. It's nowhere near as convenient as mounting a directory remotely, but it is far more secure.

    --
  • The orginal version 10.0.0 had no openssl or openssh.

    Yeah, but the public beta did have OpenSSH and OpenSSL. The first retail release did not have crypto because not everything got worked out with the government in time.

    I've been told that the reason older versions of OpenSS[H/L] were included with the update was the same reason -- it takes time to get approval for newer software. I'm not sure how true this is, just what I was told.

    - Scott
    --
    Scott Stevenson
    WildTofu [wildtofu.com]
  • I have to agree with that. I'm not a BSD person myself (yet, but I've been thinking about playing broadening my horizons a bit) but I think that would be cool.

    --

  • I use netatalk on my LinuxPPC boxes. I don't have much time to spend on configuring it (it's pretty simplistic as it is) but it seems like you can configure netatalk to encrypt the auth. There is a "uams" directory. I can't say for sure or not but I'm pretty sure you can do it. You might want to check in on a newer version over at their new website [sourceforge.net]. Development picked up again a while back. Good luck buddy.

    --

  • Thanks Apple (Score:4)

    by macdaddy ( 38372 ) on Thursday May 24, 2001 @07:29AM (#201071) Homepage Journal
    Thanks for taking a step or two towards security responsiblity. It's nice to see a company step up to the plate and swing once in a while. If you can maintain or even better improve security with your OS's, you can take a much needed step in front of a number of other companies that don't worry about security concerns until their blunders go public and threaten to hurt their bottomline or public image. Security never has ben a major problem for Apple because very little can be done to a Mac remotely. Now with OS X upon us, those old beliefs are out the window. I'd personally like to see Apple take the initiative to install the operating system in a very secure state. Pre-configure TCP wrappers in a DENY ALL state. Turn off everything that doesn't absolutely have to be on. Wrap everything wether it's on or not. Even packet filter certain things would be nice. Take the initiative to make things a litle more secure, unlike Irix and Redhat that tend to turn on way more services than are really needed. That could greatly limit the number of security concerns now and down the road. Sure you may find a new sploit for ftpd down the road but if it's already disable and/or secured to allow access only to a few hosts.... Of course this is just my opinion, I could be wrong.

    --

  • Sadly, the previous poster hasn't updated his software in some time. The current version of netatalk allows three different encryption schemes, one of which is triple DES. Should be secure enough for him...
  • Actually, they did quite a bit a testing against recorded voices, using a variety of media. The testing showed it was VERY difficult, if possible at all, to beat with a recording.
  • Comment removed based on user account deletion
  • Any system, at least any widely available system, can be owned if you have access to the hardware. There have been many Solaris, Linux, and AIX machines at left by people with unknown root passwords that I've needed to "fix". Three minutes later with the right boot media, that's no longer a problem. Sometimes boot media isn't even required.

    One new feature in the Open Firmware updates for Mac is a setting that will prevent booting from CD. It's still defeatable if you can open the box and rearrange the RAM (safety feature for people that might get stuck with $2000 paperweights), but it works.

  • If you are that paranoid, you better have a good, secure compiler.
  • Is the the MacOSX equivalent of OpenSSL?

    (I'd assumed that OpenSSL would work on MacOSX, given all the spiel about it being Unix based.)
    --
    Too stupid to live.

  • Of course, they could always just ship Aqua for OpenBSD... ; )

  • Re:Is this even a valid observation? (Score:3)

    by Noer ( 85363 ) on Thursday May 24, 2001 @07:40AM (#201079)
    Hardly. Microsoft is a minority shareholder, and hardly has much weight to throw around in that manner.

    The main leverage Microsoft has on Apple is the threat of cancelling MS Office for the Mac. But that does make MS a ton of money, so they're not just doing it for leverage purposes.

  • Good first step (Score:3)

    by Noer ( 85363 ) on Thursday May 24, 2001 @07:45AM (#201080)
    This seems like a good first step for Apple to be taken more seriously, especially given public concerns about Apple not taking security seriously.

    I'm glad to have the opportunity to look into this framework now. Hopefully Apple will keep addressing the security holes that'll pop up elsewhere in the OS from time to time.

    Will this silence the rabid anti-Apple critics who haven't used a Mac since 1984 (if ever)? Not a chance.
  • Unless Apple releases it's code for Microsoft systems

    Any code posted on their Publicsource [apple.com] site is open for all comers. For example, OpenPlay runs on Mac, Win, and various *nixes.

    As for CDSA, a couple other people are already working on Windows [intel.com] and Linux [sourceforge.net] implementations.

  • Is apple going to give MS authenticode a run for its money? I doubt it.
  • Hmm, on a barely related note. doesn't MS has a stake in Apple? Isn't apple just another faceless drone company with the big Gates behind it? ;-)
  • Apple does not recommend the use of Voiceprint unless the user has a high quality microphone -and- has the audio inputs set to 16 bit / 48 kHz. It's too easy to defeat otherwise

    Bummer. I guess this means I would need to use at least this high quality of a tape playback to defeat it.
  • MacOSX ships with almost all of its services turned off, as did Mac OS 9 and its predecessors

    Mac OS 9 and predecessors, don't ship with very many services. AFP, Personal Web Sharing.

    Just a very few years ago, this list was only AFP. Apple's AFP at least doesn't send passwords in the clear. (Unless client is a Mac, and server is a Linux box. See my other posting in this story titled AppleTalk exploits.)

    As for security, AFAIK, there have never been any exploits. Very few things on Mac work in such a way that there could even be such a thing as a format string attack. You probably wouldn't find a lot of buffer overflows. Originally, MacOS was all done in Pascal, with a length byte for all strings instead of the zero-terminated C strings.

    Even if you found a buffer overflow... What could an exploit do? There is no command shell. No pipes. No command line. No handy large library of pre-installed stuff like telnet, ftp, tftp, bash, netcat, etc.

    This is probably why Mac OS has always been the most secure. There is nothing there to exploit. Even if you run a MacOS hosted web server, there just isn't anything there to exploit.
  • Sounds like you need to go to a MacOS only solution

    That depends on the problem definition.

    In this case, the problem is:

    I've got a Linux box at home. I want to access files on it from work. AFP over TCP is great -- except for the plaintext password.

    In this case, a Mac OS only solution, wouldn't be a solution at all. I also have some Macs at home and access two of them over the Internet in the same way. (Some of them are really old.) But only in the case of the Linux running Netatalk is there a security issue.

    I wouldn't dare do this with samba to allow my Windows box at work to access my home directory at home over the Internet. I think there's just not enough people who know to grab passwords out of the AFP over TCP protocol.
  • Hey thanks for the info!

    I'll look into it.

    I don't do the remote-mount thing very often. So I don't tend to worry about it. I tend to change my password later that evening when I get home. (Paranoid.)

    I use SuSE 6.4, and use the Netatalk that came with it. It's super easy to set up. (Unlike some of the setup nightmares I've read on usenet of people trying to set up Netatalk on other distributions.)
  • It's called Program Linking. And I had forgotten all about it. You're right. You could execute a remote script, if Program Linking were turned on. Not just in AppleScript either, but in any language for which you have a suitable scripting agent installed.

    Still, this is not exactly like having a shell. But you could, theoreticaly, send suitable AppleEvent's to the Finder to manipulate files, launch programs, etc. Of course, I suspect the knowledge to do this is not common to most crackers who seem to confine themselves to Unix & Windows.
  • Thanks for the info. I stand totally corrected.

    I am running SuSE 6.4, shipped in April 2000. Over a year old. I tend to install every update I can get my hands on. But I'm running the Netatalk that SuSE provides.

    I'm looking forward to updating to SuSE 7.1 soon. Maybe this will improve the Netatalk.
  • Mac users won't turn on any of them except for Mac file sharing, which should be pretty safe; I don't know of any AppleTalk exploits.

    Just because there are no exploits, doesn't mean you have security. (See my last sentence below.)

    I remember from an Apple developer's conference about 1987 (yes that's EIGHY seven) that when the password traverses an AppleTalk network, it is DES encrypted, or something like that.

    In recent years, you can use AFP (Apple Filing Protocol) over TCP as well as over AppleTalk. Now I don't know about Apple's implementation of AFP over TCP, but when I use a Netatalk server on a Linux box, the password is in the clear. Apparently, Netatalk doesn't have or use a UAM on the Mac side to scramble the password. Even bad ol' Microsoft does this -- although you need to use a custom UAM from MS to access AFP on an NT Server from a Mac. But it's easy, just drop the UAM into your System Folder. And has been this way for years. (UAM = <something> authentication module, or somesuch.)

    At home, on Cable Modem, I have a Linux box, static IP, domain name. At work, using my Mac I sometimes mount my home directory using AFP. It's so easy. Just go to the chooser, mount it, etc. My home directory from Linux at home on my Mac desktop at work!

    I've often suspected that the password goes naked (in the clear). I just now positively confirmed it. I ran Ethereal (from a Win98se box), while I mounted my home directory from home (Linux) to my Mac desktop. Yup, the password is in the clear. It's right there in the packets.

    The next logical step is to write the cute dude responsible for dsniff to see what the possibilities are to get dsniff to reveal AFP passwords over TCP.

    The irony of this is that Mac mounting an AFP server volume is insecure only when the server is a Linux box. (well, actually Netatalk)
  • Darwin makes Mac cloning possible

    You mean like RevRDist?! [purdue.edu]

    Damn -- I was surpised to hear that what I was doing in 1997 has only this year become possible. If only I had listened to informed people like you, then I would've known better.

    Seriously though, RevRDist is great stuff. If you like Macs, especially if you work with them, you owe it to yourself to learn how to work it. It takes some hacking: ResEdit, diffing files, understanding the Gestalt function, etc. It saves alot of work and maintenance in the long run, and you learn a lot about the MacOS at the file/resource level.

  • Nonetheless, it's part of the MacOS distribution. And since you'd need a copy of some MacOS anyway for this hypothetical clone hardware, you'd get all the needed files (as evidenced by the fact that you can take a blank HD that has had nothing to do with Apple and install successfully on it).
  • The ROM in ROM is also known as Open Firmware; it's covered by an IEEE standard (off the top of my head, 1275?) and is also used by Sun (and I think a few other Unix-hardware makers) for their hardware. Not exactly proprietary...
  • Apple's got themselves in an interesting situation here. The more low-level stuff they put out for all to play with, the harder they lock down the high-level stuff.

    Seems to me that Apple's in kind of a strange situation -- Darwin makes Mac cloning possible, at least for small operators. Apple needs to do some fast thinking at this point -- going completely Open Source is a good idea because MS-style licensing enforcement at this point goes out the window. But that means they need to start moving boxes, and more importantly, motherboards.

    No doubt this is an interesting place for Apple to be working. They are giving up control, hopefully looking ahead to a point where software licensing is meaningless. That's good. Giving away an extensible crypto architecture is even better (not to mention that it makes hash of what little is left of export controls on crypto).

    Apple should stay the course. Their next trick, though, needs to be establishing a commodity PowerPC hardware market. I'd be interested to see how that can be pulled off...

    /Brian
  • Why couldn't they create MacOS X/x86 easily?

    My thought on the matter: get a Sandpoint board or something similar, get Darwin running on it, then copy over all the rest of the system and see if it will work. Unless they are in fact making high-level components hardware-dependent, it should work. Maybe not flawlessly mind you (Apple System Profiler would probably choke), but unless Apple's pulling some kind of funny business like was suggested above it shouldn't really be a problem... That is, after all, what microkernels are for...

    /Brian
  • Which is why I figure that porting it should be possible...
  • No, but it's a good start. Unfortunately, any Mac can be accessed by anyone with a copy of the Mac OS 9 cd. All they need to do is put the cd into the tray and hold down the "c" key after hitting the reset switch. The machine will boot off the cd, and allow access to any file on any of the drives attached. Copy, delete, do what you like.

    The same is true for AIX (with an AIX cd and a couple different keys of course)
  • It's open code, so any back doors are exposed. You can hide that sort of thing in binary, but not in source.
  • that some genius NSA agents have somehow subverted compilers so that they magically realize that they are compiling security-related code and insert a back door into one's code. If you compile the code, I'm sure it's clean. no need for a "secure" compiler. In fact, I don't even know what that would be. All I was saying is that usually you can't see the code that makes the binary so you dont' know what's in it.
  • This may be somewhat redundant, but Apple does not recommend the use of Voiceprint unless the user has a high quality microphone -and- has the audio inputs set to 16 bit / 48 kHz. It's too easy to defeat otherwise.
  • what is clear, and certain, is that neither one of you trolls matter even as much as a gnat buzzing around an elephant... go fuck off and die, s'il vous plaît, il y a un bon garçon
  • WIth OS X and OS 9.x, the password is encrypted...

    Sounds like you need to go to a MacOS only solution. OR you should get to work updating the Netatalk code...Open source is never broken, it's just got a long to-do list, or has fallen out of maintenance.
  • Wouldn't you need at least shell access to exploit that? All remote logins are disabled by default so wouldn't one have to be in the same room as the machine to exploit? To wit, you could only hack en masse is you were in a very big room with lots of X boxen. Or am wrong.
  • It seems not long ago there was a story about Apple taking from Open Source and not giving anything in return. Proof that they have. No, it's not the entire OS like many would want but it's better than many for-profit companies (ahem..Microsoft).

    Baby steps people.
  • No - Microsoft bought a pittance of non-voting stock some years ago and promised to continue producing Office for the Mac to settle some pesky lawsuits Apple had brought against them.
  • Sorry. Forgot to grammer check. Duh.

    Thank god /. has such low standards ;)

  • Oh yeah! Well we can perform code signing AND encryption operations while maintaining the security of the cryptographic keys AND chew gum AND standing on our heads, walking backwards. Did we mention that it will cost a lot more?

  • the keys that the NSA will want.
  • Its good to see apple getting into secure
    communications. At least some segments of end
    user population will start using crypto on daily
    basis.

    Apple is notorious though for looking at something
    that has potentia (gui, networking) and taking
    clean page, start from scratch taking some ideas,
    make so-so implementation and start selling it,
    like its the only thing acceptable to end users.
    What should've happend is they should at least
    bought out PGP industries, and cut time and
    development costs, but that would be alot like
    Microsoft. Or should've taken GPG framework and
    promote just that. Just do code audit, compared
    to whole redesign. GPG should be LGPL, I think,
    because it sole purpose is not to compete with
    PGP, but rather get everybody to use crypto
    whatever the cost is. Now starting to use crypto
    is somewhat time consuming and cumbersome.
    There are too many standarts, as from end
    users prospective.

    This is overall good move from Apple's side.
    I hope they will not make crypto that is licenced
    default in whatever software/recommendations, so
    we all can communicate, by lowest common
    denominator cipher that is available.
  • Buried at the bottom of the introduction to Part I are the interoperability goals. Compliance has always been difficult to enforce; one of the most comical stories of this was IBM's attempt to enforce the CUA (user interface). They spent gobs of money trying to make sure that everyone respected the specifications to absolutely no avail. What's really interesting is that the document doesn't even try to explain how compliance will be definitively assured. They do suggest a few things but then:
    Industry support could be demonstrated by voluntary participation in interoperability testing events organized by standards organizations, or a committee of active, CDSA developers.
    Hooray! Perhaps Apple is realizing that standing on a soap box and screaming "my closed OS is better!" isn't as prudent as simply making a good spec and offering it to the public.
  • Unless Apple releases it's code for Microsoft systems (it might, given it's streaming server and Quicktime softwares).

    Apple code for Apple OS, right?

    Geek dating! [bunnyhop.com]
  • Now, lots of folks are going to start reading this and trying to imagine lots of ways they could break this, the possible downsides, etc. Yes, it's not completely foolproof...

    No, but it's a good start. Unfortunately, any Mac can be accessed by anyone with a copy of the Mac OS 9 cd. All they need to do is put the cd into the tray and hold down the "c" key after hitting the reset switch. The machine will boot off the cd, and allow access to any file on any of the drives attached. Copy, delete, do what you like.

    Granted, you can't open specific files that have been encrypted by the system. But like I said, it's a start.

    What's even more interesting in my opinion is that Apple has recognized this vulnerability and finally released an Open Firmware update [apple.com] that password-protects the machine before the OS is loaded - either from the cd or internal hard drive.But they don't recommend using it [apple.com].

    OS 9 will never have security that's on par with any *NIX OS (it's just not multi-user at its heart), but it is better than nothing.

  • No, it doesn't. Darwin alone isn't much more than a BSD variant, and I'd be pretty surprised if Apple isn't using the copyrighted ROMs on every Mac's motherboard as some sort of dongle for the higher-level Mac OS X functionality.

    I may be wrong, but Macs stopped shipping with those OS ROMs a long time ago... so I think you're totally off base.

  • Windows 2000 has an equivalent of the keychain, the DPAPI, documented at http://msdn.microsoft.com/library/psdk/crypto/cryp toref1_0lwh.htm.

    Windows NT utilized a third party package to provide similar capabilities, the PStoreAPI.

    Richard Bondi
  • Oddly enough, Darwin has insecure setuid scripts. It also has the setuid race condition kernel bug that has been excised from more civilized Unixen. Until Mac OS X came along, such boxes were becoming scarce. It's like deja vu all over again! It's hard to believe a company would ship a "new" operating system with this same old crap in it.

    Here's hoping someone at Apple fixes this before someone else not at Apple finds a way to hack the soon-to-be-masses of Mac OS X boxen en masse.

  • Re:All that security, but insecure setuid (Score:3)

    by MichaeI Sims ( 454687 ) on Thursday May 24, 2001 @07:27AM (#201116)
    That's true, but MacOSX ships with almost all of its services turned off, as did Mac OS 9 and its predecessors. For instance, the two services (ftpd and ntpd) which were the subject of recent Apple advisories [apple.com] are not enabled in the default configuration. So it will still take a substantial amount of work to get a shell on an OS X desktop from which an attacker can exploit the local vulnerabilities.

Slashdot Top Deals

I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham

Close