It does. What I want to add is an extension to place a button that says "Load Images" at the top of the message display, allowing me to load remote images just for a particular message without generally enabling the feature. It's currently quite inconvenient to unblock images for one message.
Even farther off-topic, but one of my favorite features of Apple's Mail.app is the ability to turn off remote image loading by default, and throw a big button at the top of the message that says "Load Images". Then you can load images just for that message without opening yourself up to web bugs on a general basis.
It's a great feature if you're forced to correspond with folks who you can't LART for sending HTML mails but wish to keep your spam rate down:-)
I've been thinking about throwing an extionsion together for Thunderbird with that feature... I really should do that.
The problem with an embedded image bug is that if the recipient views the source of the email -- and presumably this alleged extorter is a techie -- it's easy to spot such a bug, and so there's a real risk that including a bug would tip him off to the investigation.
Only when you're doing mass mailings. If it's targeted, it is indistinguishable from a standard image... e.g.
http://corporate.bestbuy.com/images/corporatelog o. jpg
could be a web bug if you only send that URL to one person. The reason it's more obvious in mass mailings is because they require a unique identifier to have something to map back to the email address such that they can verify the address as live.
Exactly. I sure wouldn't try it either. (I'd be worried about two things: 1. The dire consequences of getting caught. 2. As soon as someone demonstrated the willingness/ability to use this hole for any reason, they'd probably close it. Since the ability to print my boarding pass from home has saved me tens of hours, I really don't want that.)
How do you propose to check in, when they look at the name as it is returned from the database, and it doesn't match your ID?
You haven't flown recently, have you? It is trivial to check in without anyone checking your ID against the database, so long as you have no baggage. Heck, someairlinesevenofferonlinecheckin from home. If you need to check a bag, though, you're right.
If cox is like rcn, OP meant that they block port 25 outbound as well. I got rid of RCN for just that reason. I access my mail server by connecting to it on port 25, then issuing STARTTLS to encrypt my connection. They didn't understand why I didn't want to send my mails over their server. When I complained, they told me that they weren't doing this to their static customers at the moment, and that I could have a static IP for an extra $20/month. They were unwilling to promise that they would not institute the same policy for static users, though. I told them that for an extra $20/month I could have a good ISP (less than $20, actually!) whose TOS essentially promise to leave you alone, and proceeded to vote with my wallet.
I didn't spend a ton of time picking through your thread, but did you take an image of the filesystem and work off that instead of the original? If you did, and you still have the image around, you may be interested in The Sleuth Kit... it claims to support ext3. I haven't tried it myself but plan to throw together a junk box and give it a try. It looks useful. If it makes you feel any better about your choice of filesystem, recovering deleted files is *damned hard* on NTFS as well... it's only the old FAT?? systems that really have a leg up on Linux anymore:-)
This is not exactly a "crack" in the DRM scheme. It's not even very interesting. First off, even if the author manages to produce working code (as well he should, IMO), it will only work on AAC's that you are licensed to play and export. Secondly, everyone, even Apple, acknowledges that their DRM has a hole so large you could drive a truck through it. Their own software gives you the ability to export to an unprotected digital format: the audio CD.
It's also noteworthy that similar code has been circulating quietly for quite some time on the Mac side. Anyone with even moderate knowledge of the QuickTime APIs could implement code to do this with minimal effort. It's trivial. I myself have written code that re-encodes the protected AAC's to MP3 so that I can play them on an old Rio that I still use sometimes. It's such a small bit of obvious code that I've never bothered to distribute it; anyone who needs it can produce it themselves. Hell, it may even be available here. If not, one of the QuickTime samples requires only small modifications to make it work.
I guess we should all say, "Way to go, Mr. Johansen. You've demonstrated the ability to learn the QuickTime API. Congratulations." Did he feel the need to publish his first "Hello, World" on the web as well? (I don't wish to disparage his work on DeCSS... that was good. This is not on the same scale at all, though!)
The authors need a little perspective. From the story:
Nobody has more expertise in porting software to different platforms than the Debian project.
They also state that it may be the most broadly deployable OS in existance because it runs on 11 architectures. No mean feat, I'm sure. But others run on more platforms. At least 17 CPU architectures and who knows how many "platforms":-) Still, I'm excited about this new installer and can't wait to see if/how PGI integrates with it. Apart from this small (and very excusable IMO) bit of myopia the article does a great job of walking you through what to expect... definitely worth saving the link to read when the slashdotting is over if you can't get to it now.
I see... I don't think I've ever used (or been aware of, even) the ability to send and receive files via MSN. Oddly enough, I don't think this would make me enable UPnP for my router even if I could... I'd prefer to manually open the ports or use a proxy, I think.
The MSN Messenger protocol requires you to listen to certain ports and if you're behind a NAT firewall then it doesn't work properly so it uses UPNP. From what I gather, anything which knows about UPNP can request ports to be opened.
Umm... no. The MSN Messenger protocol does not require you to listen to certain ports and works just fine from behind a NAT firewall which has no open ports and does not support UPNP at all. It also works just fine when running on a system with UPNP completely removed. Where did you get your information? (I'm not saying some braindead router wouldn't accept entries via UPNP, just that I know for a fact that the MSN Messenger protocol does not require such functionality!:-))
The plans by two of the largest consumer goods companies to spend a significant amount of promotional money on music sharing is a validation of Apple's revolutionary iTunes service - and a ringing endorsement for the beleaguered music industry.
It seems like not too long ago, every time you'd see mention of apple in the press, they were called "beleaguered". It became kind of a running joke on Mac sites. Well, now we're once again seeing "Apple" and "beleaguered" in the same sentence, but in a good way. I think I'm going to start referring to them as "the beleaguered RIAA" from now on:-)... with any luck, the MPAA and SCO will soon join their ranks.
Dunno about you, but I'm fed up with standing next to a KVM'd keyboard/monitor in our chilled computer room with all the fans going - now I can kick the install off in the machine room, and go back to my desk to see it through.
No doubt. On top of that, our KVMs are incredibly un-ergonomic to use... your neck is at an uncomfortable angle looking at the screen and the keyboards with the stupid built-in trackball are crap. I didn't even think about that since it'd been so long since I'd had to do an install in the server room. Not to mention, if, as AC suggested, I tweak the ISO to start in VNC mode automatically, I can send that CD to a remote site, have the NT-oriented PFY there insert the CD in the new server, and complete the install remotely without having to talk the poor kid through every option. I'm curious to see how it works. i.e., whether it's displayed on the local framebuffer as well or can be shared. If so, it will make a useful training tool for said admin:-)
Installation via VNC is now supported. To initiate a VNC-based installation, pass vnc as a boot-time option. If necessary, a password can be set by adding "vncpassword=<password>" to the boot-time options. The VNC display will be "<host>:1", where <host> is the hostname or IP address of the system installing Fedora Core.
It is also possible for the Fedora Core installation program to initiate a connection to a listening VNC client. This is done by using the vncconnect boot-time option[...]
That's really cool, and more useful than it sounds... I was looking for just this feature several months ago when installing RH on a laptop whose video card was supported by XFree but for some reason wouldn't work with the graphical installer. (Tweaks were required for the configuration file.) I know there's a text-based installer as well, but it's so much easier to select packages on the GUI install. It sounds like this will be a nice successor to RH 9.
Instead of a "wait and see" approach, might I suggest a "read and comprehend" one.
Only if you agree to try it yourself.
Because Apple declined to comment, their current intent is not known. If you read the quote from the article:
"In my initial conversations with them, they said they weren't going to fix 10.2, but I wouldn't be surprised if they change that," he said.
Note the past tense. The key phrases "initial conversations" and "I wouldn't be surprised if they change that". The lack of any statement as to their current intent from either Mr. Goldsmith or an Apple mouthpiece. In short, a non-story.
You seem to have mistaken my post for a defense of Apple rather than a criticism of yet another sensationalized, moronic article on C|Net.
Most of it only speculates as to Apple's intent. Here is the only part relevant to their actual intent:
Apple declined comment.
Sure, they should have pronounced their intent to fix the problems but they have certainly NOT stated that the intent is to leave 10.2.x unpatched.
The article is a bit misleading, as well. For instance, it fails to note that the @stake advisory in question (core files can be used to overwrite arbitrary files) pertains to a facility that is disabled in all Apple-supplied 10.2 installations.
In short, they should fix it. Soon. They haven't said they won't, though, and it's been *almost* two days. I'm taking a "wait and see" approach on this one.
>
I've never really understood why people kick up such a fuss about unwanted email.
You've never paid by the byte for your data transfer, then, have you? I imagine you've also never paid for your storage space or paid by the minute for your connection time. Any of these things make spam suck much worse. Also, it really sucks if you get so much spam in your mailbox that your provider starts bouncing legitimate messages. These conditions (among others) can cause unwanted email to become costly rather than merely annoying.
>
I never hide my email when posting on forums or anywhere online.
It'd be interesting, however, to see if something like iTunes would easily build against GNUstep.
No, it wouldn't really be interesting... It obviously simply wouldn't work. iTunes is a Carbon application, while GNUStep is an implementation of the OpenStep framework, which Apple updated and rebadged Cocoa. Even if the GNUStep libraries were up to the current Apple standards, you'd never manage to build a Carbon application against them:-) The only way the two are really even similar is that they're both used on Mac OS X to build GUI applications. It's a lot like saying "It'd be interesting, however, to see if something like KDevelop would build against gtk+."
They mostly seem to be going for the lowest MX on the list, so simply:
Obtain an additional IP address for your primary MX box.
Configure that as your tertiary MX, with, say, a priority of 100
Configure the MTA on that box to feed your Bayesian filter with all the spam you'll get, then delete it without transferring to your inbox:-)
The critical thing is that you need to be certain that this tertiary MX is only up when your primary MX is also up. No legitimate mail software will use an MX with a priority of 100 when it can connect to an MX with a priority of 1, so you can be certain that anything the 3rd MX gets is spam. If they're on different boxes, however, a simultaneous outage of the first 2 could cause you to accept then dump legitimate messages.
I think the reason the version number wasn't modified is that the OpenSSL group found out about this problem well in advance of its public release and notified a group of vendors in confidence. Apple probably only applied patches for the 4 particular bugs in question rather than updating to the current version. The public release wasn't until 9/30; Apple wouldn't have had it in 10.2.8 but rather in a separate security update if they hadn't gotten it until then.
To convince yourself of this, you can do compile and run the following[1]:
If you save it to the file "sslversion.c", compile it with the command: gcc -lcrypto -o sslversion sslversion.c
When executed, you can see:
OpenSSL library version info: OpenSSL 0.9.6i Feb 19 2003 Build options: compiler: cc -arch i386 -arch ppc -g -Os -pipe -Wno-precomp -arch i386 -arch ppc -pipe Build date: built on: Sun Sep 14 16:49:23 PDT 2003
IMO that confirms the fact that Apple had advance notice and had to patch 0.9.6i rather than updating to 0.9.6k. I agree that it is obnoxious that they don't give some indication of this, e.g. OpenSSL 0.9.6i patch X or similar. I've had a similar beef with Red Hat for some time. I think I'll file a bug with Apple.
[1] The value of compiling and running your own is to make sure you're getting the default system library; I'm not sure how the openssl application was built, and this problem was in the library not in the openssl executable.
It's really not unclear at all... I received the following in my inbox:
[ message edited slightly due to lameness filter ]
APPLE-SA-2003-10-03 Mac OS X 10.2.8 Revised
Mac OS X 10.2.8 has been re-posted, and it is updated to address issues discovered with certain system configurations. The security enhancements in Mac OS X 10.2.8 are identical between the first release and the one now available.
This note describes all security enhancements in Mac OS X 10.2.8, with the following new information:
* Security enhancements for OpenSSL (details below) have been recently announced, and we can now disclose the presence of these enhancements in Mac OS X 10.2.8.
* The latest release of Mac OS X 10.2.8 includes support for PowerMac G5 systems. The initial 10.2.8 release only applied to PowerMac G4 systems.
* A Sendmail workaround for Mac OS X 10.1.x systems is described below.
Mac OS X 10.2.8 contains security enhancements for the following:
OpenSSL: Fixes CAN-2003-0543, CAN-2003-0544, CAN-2003-0545 to address
potential issues in certain ASN.1 structures and in certificate
verification code. To deliver the update in a rapid and reliable
manner, only the patches for the CVE IDs listed above were
applied, and not the entire latest OpenSSL library. Thus, the
OpenSSL version in Mac OS X 10.2.8, as obtained via the
"openssl version" command, is: OpenSSL 0.9.6i Feb 19 2003
OpenSSH: Mac OS X 10.2.8 contains the patches to address CVE
CAN-2003-0693, CAN-2003-0695, and CAN-2003-0682. On Mac OS X
versions prior to 10.2.8, the vulnerability is limited to a denial
of service from the possibility of causing sshd to crash. Each
login session has its own sshd, so established connections are
preserved up to the point where system resources are exhausted by
an attack.
To deliver the update in a rapid and reliable manner, only the
patches for CVE IDs listed above were applied, and not the entire
set of patches for OpenSSH 3.7.1. Thus, the OpenSSH version in
Mac OS X 10.2.8, as obtained via the "ssh -V" command, is:
OpenSSH_3.4p1+CAN-2003-0693, SSH protocols 1.5/2.0, OpenSSL
0x0090609f
fb_realpath(): Fixes CAN-2003-0466 which is an off-by-one error in
the fb_realpath() function that may allow attackers to execute
arbitrary code.
arplookup(): Fixes CAN-2003-0804. The arplookup() function caches
ARP requests for routes on a local link. On a local subnet only,
it is possible for an attacker to send a sufficient number of
spoofed ARP requests which will exhaust kernel memory, leading to
a denial of service.
Sendmail: Addresses CVE CAN-2003-0694 and CAN-2003-0681 to fix a
buffer overflow in address parsing, as well as a potential buffer
overflow in ruleset parsing.
How to install Sendmail for Mac OS X 10.1.5 systems:
- - From the UNIX command-line, perform the following steps:
1. Download sendmail version 8.12.10 which contains the fix to the Zalewski advisory, released on 2003/09/17, by executing the following command: curl -O ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12. 10.tar.gz
2. Verify the integrity of this file by typing: cksum sendmail.8.12.10.tar.gz which should indicate "834313764 1892497 sendmail.8.12.10.tar.gz"
3. Unpack the distribution as follows: tar xvzf sendmail.8.12.10.tar.gz
4. Add the following line to your/etc/master.passwd file: smmsp:*:25:25::0:0:Sendmail User:/private/etc/mail:/usr/bin/false
5. Add the following line to your/etc/group file: smmsp:*:25:
6. Now invoke/Applications/Utilities/Netinfo Manager.app and add the same smmsp user and group entries to your netinfo database. The easiest way is to dup
Slashdot Mirror
It's a new feature in 10.3's mail.app.
It does. What I want to add is an extension to place a button that says "Load Images" at the top of the message display, allowing me to load remote images just for a particular message without generally enabling the feature. It's currently quite inconvenient to unblock images for one message.
Even farther off-topic, but one of my favorite features of Apple's Mail.app is the ability to turn off remote image loading by default, and throw a big button at the top of the message that says "Load Images". Then you can load images just for that message without opening yourself up to web bugs on a general basis.
:-)
It's a great feature if you're forced to correspond with folks who you can't LART for sending HTML mails but wish to keep your spam rate down
I've been thinking about throwing an extionsion together for Thunderbird with that feature... I really should do that.
The problem with an embedded image bug is that if the recipient views the source of the email -- and presumably this alleged extorter is a techie -- it's easy to spot such a bug, and so there's a real risk that including a bug would tip him off to the investigation.
g o. jpg
Only when you're doing mass mailings. If it's targeted, it is indistinguishable from a standard image... e.g.
http://corporate.bestbuy.com/images/corporatelo
could be a web bug if you only send that URL to one person. The reason it's more obvious in mass mailings is because they require a unique identifier to have something to map back to the email address such that they can verify the address as live.
You often have an audience of geeks watching Blue Man Group at The Charles Playhouse in Boston. The performers are stranger, hands down :-)
Exactly. I sure wouldn't try it either. (I'd be worried about two things: 1. The dire consequences of getting caught. 2. As soon as someone demonstrated the willingness/ability to use this hole for any reason, they'd probably close it. Since the ability to print my boarding pass from home has saved me tens of hours, I really don't want that.)
You haven't flown recently, have you? It is trivial to check in without anyone checking your ID against the database, so long as you have no baggage. Heck, some airlines even offer online checkin from home. If you need to check a bag, though, you're right.
If cox is like rcn, OP meant that they block port 25 outbound as well. I got rid of RCN for just that reason. I access my mail server by connecting to it on port 25, then issuing STARTTLS to encrypt my connection. They didn't understand why I didn't want to send my mails over their server. When I complained, they told me that they weren't doing this to their static customers at the moment, and that I could have a static IP for an extra $20/month. They were unwilling to promise that they would not institute the same policy for static users, though. I told them that for an extra $20/month I could have a good ISP (less than $20, actually!) whose TOS essentially promise to leave you alone, and proceeded to vote with my wallet.
- USB
- USB
- PS/2
- PS/2
Or, if you don't want Belkin to get another dollar of yours due to the recent BS they pulled with their routers, there are many others:- PS/2
- fancy optical
- fancy wireless and optical
- PS/2
That's just what I found during 10 minutes of STFW. And I didn't take all the abuse you did by asking hereI didn't spend a ton of time picking through your thread, but did you take an image of the filesystem and work off that instead of the original? If you did, and you still have the image around, you may be interested in The Sleuth Kit... it claims to support ext3. I haven't tried it myself but plan to throw together a junk box and give it a try. It looks useful. If it makes you feel any better about your choice of filesystem, recovering deleted files is *damned hard* on NTFS as well... it's only the old FAT?? systems that really have a leg up on Linux anymore :-)
This is not exactly a "crack" in the DRM scheme. It's not even very interesting. First off, even if the author manages to produce working code (as well he should, IMO), it will only work on AAC's that you are licensed to play and export. Secondly, everyone, even Apple, acknowledges that their DRM has a hole so large you could drive a truck through it. Their own software gives you the ability to export to an unprotected digital format: the audio CD.
It's also noteworthy that similar code has been circulating quietly for quite some time on the Mac side. Anyone with even moderate knowledge of the QuickTime APIs could implement code to do this with minimal effort. It's trivial. I myself have written code that re-encodes the protected AAC's to MP3 so that I can play them on an old Rio that I still use sometimes. It's such a small bit of obvious code that I've never bothered to distribute it; anyone who needs it can produce it themselves. Hell, it may even be available here. If not, one of the QuickTime samples requires only small modifications to make it work.
I guess we should all say, "Way to go, Mr. Johansen. You've demonstrated the ability to learn the QuickTime API. Congratulations." Did he feel the need to publish his first "Hello, World" on the web as well? (I don't wish to disparage his work on DeCSS... that was good. This is not on the same scale at all, though!)
The authors need a little perspective. From the story:
They also state that it may be the most broadly deployable OS in existance because it runs on 11 architectures. No mean feat, I'm sure. But others run on more platforms. At least 17 CPU architectures and who knows how many "platforms" :-) Still, I'm excited about this new installer and can't wait to see if/how PGI integrates with it. Apart from this small (and very excusable IMO) bit of myopia the article does a great job of walking you through what to expect... definitely worth saving the link to read when the slashdotting is over if you can't get to it now.
I see... I don't think I've ever used (or been aware of, even) the ability to send and receive files via MSN. Oddly enough, I don't think this would make me enable UPnP for my router even if I could... I'd prefer to manually open the ports or use a proxy, I think.
Umm... no. The MSN Messenger protocol does not require you to listen to certain ports and works just fine from behind a NAT firewall which has no open ports and does not support UPNP at all. It also works just fine when running on a system with UPNP completely removed. Where did you get your information? (I'm not saying some braindead router wouldn't accept entries via UPNP, just that I know for a fact that the MSN Messenger protocol does not require such functionality! :-))
It seems like not too long ago, every time you'd see mention of apple in the press, they were called "beleaguered". It became kind of a running joke on Mac sites. Well, now we're once again seeing "Apple" and "beleaguered" in the same sentence, but in a good way. I think I'm going to start referring to them as "the beleaguered RIAA" from now on :-)... with any luck, the MPAA and SCO will soon join their ranks.
Dunno about you, but I'm fed up with standing next to a KVM'd keyboard/monitor in our chilled computer room with all the fans going - now I can kick the install off in the machine room, and go back to my desk to see it through.
:-)
No doubt. On top of that, our KVMs are incredibly un-ergonomic to use... your neck is at an uncomfortable angle looking at the screen and the keyboards with the stupid built-in trackball are crap. I didn't even think about that since it'd been so long since I'd had to do an install in the server room. Not to mention, if, as AC suggested, I tweak the ISO to start in VNC mode automatically, I can send that CD to a remote site, have the NT-oriented PFY there insert the CD in the new server, and complete the install remotely without having to talk the poor kid through every option. I'm curious to see how it works. i.e., whether it's displayed on the local framebuffer as well or can be shared. If so, it will make a useful training tool for said admin
My laptop had a screen and keyboard attached... the GUI just didn't work on the videocard during the install process.
It would be useful to tweak it to that mode automatically tho'.
That's really cool, and more useful than it sounds... I was looking for just this feature several months ago when installing RH on a laptop whose video card was supported by XFree but for some reason wouldn't work with the graphical installer. (Tweaks were required for the configuration file.) I know there's a text-based installer as well, but it's so much easier to select packages on the GUI install. It sounds like this will be a nice successor to RH 9.
Only if you agree to try it yourself.
Because Apple declined to comment, their current intent is not known. If you read the quote from the article:
Note the past tense. The key phrases "initial conversations" and "I wouldn't be surprised if they change that". The lack of any statement as to their current intent from either Mr. Goldsmith or an Apple mouthpiece. In short, a non-story.
You seem to have mistaken my post for a defense of Apple rather than a criticism of yet another sensationalized, moronic article on C|Net.
Most of it only speculates as to Apple's intent. Here is the only part relevant to their actual intent:
Apple declined comment.
Sure, they should have pronounced their intent to fix the problems but they have certainly NOT stated that the intent is to leave 10.2.x unpatched.
The article is a bit misleading, as well. For instance, it fails to note that the @stake advisory in question (core files can be used to overwrite arbitrary files) pertains to a facility that is disabled in all Apple-supplied 10.2 installations.
In short, they should fix it. Soon. They haven't said they won't, though, and it's been *almost* two days. I'm taking a "wait and see" approach on this one.
You've never paid by the byte for your data transfer, then, have you? I imagine you've also never paid for your storage space or paid by the minute for your connection time. Any of these things make spam suck much worse. Also, it really sucks if you get so much spam in your mailbox that your provider starts bouncing legitimate messages. These conditions (among others) can cause unwanted email to become costly rather than merely annoying.
Liar. You hide it when posting on slashdot.
It'd be interesting, however, to see if something like iTunes would easily build against GNUstep.
No, it wouldn't really be interesting... It obviously simply wouldn't work. iTunes is a Carbon application, while GNUStep is an implementation of the OpenStep framework, which Apple updated and rebadged Cocoa. Even if the GNUStep libraries were up to the current Apple standards, you'd never manage to build a Carbon application against them :-) The only way the two are really even similar is that they're both used on Mac OS X to build GUI applications. It's a lot like saying "It'd be interesting, however, to see if something like KDevelop would build against gtk+."
They mostly seem to be going for the lowest MX on the list, so simply:
The critical thing is that you need to be certain that this tertiary MX is only up when your primary MX is also up. No legitimate mail software will use an MX with a priority of 100 when it can connect to an MX with a priority of 1, so you can be certain that anything the 3rd MX gets is spam. If they're on different boxes, however, a simultaneous outage of the first 2 could cause you to accept then dump legitimate messages.
I think the reason the version number wasn't modified is that the OpenSSL group found out about this problem well in advance of its public release and notified a group of vendors in confidence. Apple probably only applied patches for the 4 particular bugs in question rather than updating to the current version. The public release wasn't until 9/30; Apple wouldn't have had it in 10.2.8 but rather in a separate security update if they hadn't gotten it until then.
To convince yourself of this, you can do compile and run the following[1]:
If you save it to the file "sslversion.c", compile it with the command:
gcc -lcrypto -o sslversion sslversion.c
When executed, you can see:
IMO that confirms the fact that Apple had advance notice and had to patch 0.9.6i rather than updating to 0.9.6k. I agree that it is obnoxious that they don't give some indication of this, e.g. OpenSSL 0.9.6i patch X or similar. I've had a similar beef with Red Hat for some time. I think I'll file a bug with Apple.
[1] The value of compiling and running your own is to make sure you're getting the default system library; I'm not sure how the openssl application was built, and this problem was in the library not in the openssl executable.
It's really not unclear at all... I received the following in my inbox:
/etc/master.passwd file:
/etc/group file:
/Applications/Utilities/Netinfo Manager.app and add the
[ message edited slightly due to lameness filter ]
APPLE-SA-2003-10-03 Mac OS X 10.2.8 Revised
Mac OS X 10.2.8 has been re-posted, and it is updated to address
issues discovered with certain system configurations. The security
enhancements in Mac OS X 10.2.8 are identical between the first
release and the one now available.
This note describes all security enhancements in Mac OS X 10.2.8,
with the following new information:
* Security enhancements for OpenSSL (details below) have been recently
announced, and we can now disclose the presence of these enhancements
in Mac OS X 10.2.8.
* The latest release of Mac OS X 10.2.8 includes support for PowerMac
G5 systems. The initial 10.2.8 release only applied to PowerMac G4
systems.
* A Sendmail workaround for Mac OS X 10.1.x systems is described
below.
Mac OS X 10.2.8 contains security enhancements for the following:
OpenSSL: Fixes CAN-2003-0543, CAN-2003-0544, CAN-2003-0545 to address
potential issues in certain ASN.1 structures and in certificate
verification code. To deliver the update in a rapid and reliable
manner, only the patches for the CVE IDs listed above were
applied, and not the entire latest OpenSSL library. Thus, the
OpenSSL version in Mac OS X 10.2.8, as obtained via the
"openssl version" command, is: OpenSSL 0.9.6i Feb 19 2003
OpenSSH: Mac OS X 10.2.8 contains the patches to address CVE
CAN-2003-0693, CAN-2003-0695, and CAN-2003-0682. On Mac OS X
versions prior to 10.2.8, the vulnerability is limited to a denial
of service from the possibility of causing sshd to crash. Each
login session has its own sshd, so established connections are
preserved up to the point where system resources are exhausted by
an attack.
To deliver the update in a rapid and reliable manner, only the
patches for CVE IDs listed above were applied, and not the entire
set of patches for OpenSSH 3.7.1. Thus, the OpenSSH version in
Mac OS X 10.2.8, as obtained via the "ssh -V" command, is:
OpenSSH_3.4p1+CAN-2003-0693, SSH protocols 1.5/2.0, OpenSSL
0x0090609f
fb_realpath(): Fixes CAN-2003-0466 which is an off-by-one error in
the fb_realpath() function that may allow attackers to execute
arbitrary code.
arplookup(): Fixes CAN-2003-0804. The arplookup() function caches
ARP requests for routes on a local link. On a local subnet only,
it is possible for an attacker to send a sufficient number of
spoofed ARP requests which will exhaust kernel memory, leading to
a denial of service.
Sendmail: Addresses CVE CAN-2003-0694 and CAN-2003-0681 to fix a
buffer overflow in address parsing, as well as a potential buffer
overflow in ruleset parsing.
How to install Sendmail for Mac OS X 10.1.5 systems:
- - From the UNIX command-line, perform the following steps:
1. Download sendmail version 8.12.10 which contains the fix to the
Zalewski advisory, released on 2003/09/17, by executing the following
command:
curl -O ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12. 10.tar.gz
2. Verify the integrity of this file by typing:
cksum sendmail.8.12.10.tar.gz
which should indicate "834313764 1892497 sendmail.8.12.10.tar.gz"
3. Unpack the distribution as follows:
tar xvzf sendmail.8.12.10.tar.gz
4. Add the following line to your
smmsp:*:25:25::0:0:Sendmail User:/private/etc/mail:/usr/bin/false
5. Add the following line to your
smmsp:*:25:
6. Now invoke
same smmsp user and group entries to your netinfo database. The
easiest way is to dup