Office 2008 Issue No.1: LIID502
The first issue relates to file ownership. Every user account on your Mac has an associated eMac OS X uses these UlDs instead of account names to track a user's access to various files and actions. When you initially set up your Mac, the first user account created is given DID 501 and has administrative access.
The second account created gets UID 502 and whatever status: admin, standard. or managed, the administer give it.
The Office 2008 installation packagc installs almost all ofits files and their
enclosing folders with the owner set to user ID 502.
If you set up the second account with out administrative privileges, it will still end up with free rein over Office's components. and therefore, the ability to delete or alter Office and many of its support files.
Typically when you install software using Apple’s Installer utility, each installed file is owned by either the system, by a specific user account as determined by the developer and laid out in the installation package, or by the user account performing the installation.
Anyway, as Bruner pointed out in one blog entry, the Office 2008 installation doesn’t do any of these things. Instead, the installation package installs almost all of its files and their enclosing folders with the owner set to user ID 502. This occurs regardless of which user account runs the installer, and regardless of the administrative status of UID 502.
If UID 502 is an administrative account on your Mac, this may not be an issue, as you’ve presumably given that account admin status for a reason.
However, if you set up the second account on your Mac without administrative privileges, that account will still end up with free rein over all of Office’s components, and thus the ability to delete or alter /Library/Fonts/Microsoft, /Library/Application Support/Microsoft, and /Applications/Microsoft Office 2008, as well as the contents of these folders. (The installation for the Special Media Edition of Office 2008 also creates the folder /Library/Automator if it didn’t already exist, and gives UID 502 ownership of that folder, as well.) For instance, the user could replace a legitimate file with something else and even make that file executable (see below).
Similarly, if you’ve set up the second account on your Mac as a non-admin account for your own everyday use—ostensibly to prevent yourself from accidentally screwing things up—this “safety” account will have the power to delete or otherwise alter the Office 2008 installation.
Many users won’t notice this situation, but it potentially poses a security issue, as it could provide a non-admin user the ability to modify files that would normally be accessible only to administrators.
Note that UID 502 will be set as the owner of Office 2008 files even if you’ve never created a second user account on your Mac—meaning your Office files will be owned by a user that doesn’t exist. This is actually a preferable scenario, as a user that doesn’t exist can’t modify files.
Office 2008 Issue No. 2: Executable Code Issue
This is the second problem is that every file in the Office 2008 installation is executable. h a security vulnerability comes to light in one of Office 200H's more than 42.000 installed files, it will be easier for hackers to exploit that vulnerability because it's in an executable file. What You Can Do Microsoft says that it will provide a free. downloadable update that fixes both problems. For a longer version of this article, with fixing instructions. go to macworid.com/3359.
If Office 2008 or 2011 are too expensive or you find no-ending problems. Open Office might be your solution. Open Office is free, works great on Mac OS X too.
Any Solutions?
Although Office 2008 is the first major Microsoft product to use Apple’s Installer system, security experts were surprised by these mistakes. “It’s not good and a clear violation of Microsoft’s standards,” said analyst Rich Mogull.
He who writes about security issues for Securosis and TidBITS as well as Macworld. “This should not have occurred considering how rigid [Microsoft’s] Security Development Life Cycle is. By potentially allowing a non-privileged user to change system-wide files, it could allow an attacker to cross trust boundaries and execute code in another user’s context.”
Mogull notes, however, that the security implications are, for now, theoretical rather than immediate: “The combination of the two issues is problematic, but it’s one of those issues we need to bring to light, not panic about quite yet.”
For its part, Microsoft takes the two issues seriously, says Geoff Price, product unit manager for the company’s Macintosh Business Unit.
Read more here
