QuickTime Pro 7.64 serial key or number

Page content loaded

Question:Q:Can't re-register QuickTime 7 Pro

item

Johann Beda

Item (if I understand correctly) laments the fact that one's AppleID/iCloud/iTunes account is identified by an email address but that email address cannot be used for manicapital.com and that one is forced to use an email address ending in manicapital.com

This is not completely correct. If you use abc@com as your email address, you can set up manicapital.com to access that email account in whatever ways the com service might allow you to access email (POP or IMAP or whatever). In order to use this email address as an identifier of your AppleID / iCloud / iTunes account you will need access to the email account in order to respond to various "yes I can access this email mailbox" types of messages that Apple will send you.

If you want Apple's iCloud system to provide you with email, there is no way for Apple to directly create an account on their system that can receive email sent to abc@com - how could they? com is a completely different company from Apple, so Apple does not have access to email delivered to mailboxes at com. Apple can only offer you email addresses at manicapital.com (or manicapital.com or manicapital.com or whatever domain they happen to be thinking is cool and they own).

Of course there are ways to get your abc@manicapital.com email forwarded to abc@com (see

iCloud: Forward all messages automatically

for example) or it might be possible your abc@com email forwarded to abc@manicapital.com, but it looks like that needs to be done on the com side of things.

If you want, you can change the identifier of your abc@com AppleID/iCloud/iTunes account to abc@manicapital.com, but once you do so, you might not be able to chanage it to anything else - see

Change your Apple ID

For the most part, I usually set up clients' AppleID / iCloud / iTunes accounts using their current email addresses, and do not set up an email account @manicapital.com for them. This does mean that they cannot use manicapital.com with iCloud, but can still setup and use "Notes" with any other IMAP accounts they have on both Mac OS X and iOS. With that said, there is some simplicity if one eliminates non-Apple stuff from the whole AppleID / iCloud / iTunes account naming - maybe it would be less confusing if I encouraged people to do that, but then people would need to deal with multiple email addresses and/or issues with forwarding email to the correct place.

item

MacInTouch Reader

If two-factor authentication is enabled for iCloud, then iCloud backups will be encrypted using a device key entangled with your passcode. *nice!*

manicapital.com

item

MacInTouch

A vulnerability in iMessage could expose photos and videos

Messages sent through iMessage are not as secure as users previously thought. Researchers with John Hopkins University discovered a vulnerability in Apple's messaging system that allows an attacker to decrypt and view sent photos and videos. The Washington Post reports that the research group successfully tested their findings on phones that weren't yet using the company's newest OS. Apple plans to patch the flaw later today with the release of iOS , at which point the researchers will release a paper on their findings.

item

Peter Lovell

A MacInTouch reader wrote:

If two-factor authentication is enabled for iCloud, then iCloud backups will be encrypted using a device key entangled with your passcode. *nice!*

Now, this means that if your device is stolen, then you can't do a restore onto a new iPhone?

How can this possibly be right??

item

Philip M

I have moved on to Mac OS El Capitan from I have a question about where it stores its Spotlight indexes.

I keep sensitive data on Veracrypt volumes, which show up as individual mounted drives when a password is given.

I was having some Spotlight issues. So I used to erase the indexes on each drive, including the main drive (/). And then turned indexing off and then on, for each one.

Now everything is working, including searching in Outlook 11 (whose identity database is on the mounted Veracrypt drive), which utilizes Spotlight.

But, the magic is, there are no Spotlight-V files on two of the Veracrypt drives, and though there are Spotlight-V files on the Outlook drive, they are sparsely populated and have not been modified since 2 30 am (the reindexing started at am and went on for hours).

Does that mean all the Spotlight data four all four drives is on my main drive? Unencrypted?

The thing about is it stored the Spotlight indexes on the encrypted drives themselves, which means, that when they are ejected, no one can get at the Spotlight data.

I don't like the fact that Spotlight finds stuff on these encrypted partitions (when they are mounted), without having its own files on those partitions.

It seems like there is an index of all my (normally encrypted) data sitting on my main drive.

Now, this does not make sense, and not just from a security standpoint. I don't think OS X can tell whether these volumes are external or not. Why wouldn't it just put Spotlight indexes on them, only to be used when they plugged in?

Can anyone sort this all out for me?

item

Anton Rang

Philip M asks about where Spotlight indexes are.

Normally, El Capitan (as did previous OS versions) stores the indexes on the drive being indexed. There are cases, such as network drives, where indexes are stored locally. I’m not familiar with VeraCrypt, so I don’t know if it sets flags on the volumes it creates to indicate that they’re a network drive, even though they’re not.

To find out where the indexes are stored, you can use the “lsof” command to see which files the mds_stores process has open: “sudo lsof -c mds_stores”. If they’re in /Volumes on your encrypted disk, then all is well. If not, you may wish to disable indexing for those volumes until VeraCrypt is updated to avoid this issue.

item

MacInTouch

Researchers find hole in SIP, Apple's newest protection feature

Security researchers have discovered a vulnerability that creates a means for hackers to circumvent Apple's newest protection feature, System Integrity Protection (SIP).

SIP is designed to prevent potentially malicious software from modifying protected files and folders. The technology is designed to protect the system from anyone who has root access, authorised or not. SIP is a key security feature of the latest version of OS X, El Capitan, as explained by Apple here.

Researchers at SentinelOne discovered a flaw that allows for local privilege escalation and bypass of System Integrity Protection, effectively circumventing the technology.

item

Davide Guarisco

Ars has a report (originally from manicapital.com but behind a paywall):

Report: Apple designing its own servers to avoid snooping

on how Apple "has begun designing its own servers partly because of suspicions that hardware is being intercepted before it gets delivered".

I find it ironic that Apple, after discontinuing the Xserve -- still under Steve -- now finds itself in a bind.

item

Steven Wicinski

Regarding the comment on Apple designing their own servers, unless the Xserves were made by Apple within Apple's facilities (which I doubt), they were and could still be subject to interception from production facility to server facility, which is a concern with any computer that is purchased from anywhere. Heck, it might not even be at the builder. Who's to say what is going into those network chips and cards?

item

MacInTouch Reader

I reported back on March 9, about the inability to get a computer running Lion () to update XProtect to version Would like to update that this computer did eventually find what it needed from Apple and updated on its own. Not sure exactly when it did the voodoo it did. Just noticed it this weekend while I was updating browsers and other such items. The new update is dated March 17, according to Safe Download Version. When it comes to XProtect, it looks like Apple is indeed still providing security updates for the older operating systems.

item

Gene L

Apple Insider is reporting apparent crashes in when people hit hyperlinks in Safari, Mail, Messages, etc.

manicapital.com

Reader comments point to installing the manicapital.com app. It appears related to Apple's Universal Links processing, which allows an app to create a link which is automatically accessed by iOS from other apps. Reportedly, manicapital.com has fixed the link to a non-lethal version.

But this has shocking implications for security!

This is the scenario:
1. A legitimate looking app is submitted. It contains no malicious or even suspicious code. Apple approves.
2. It sets up a Universal Link. Hopefully Apple checks to see if it is benign. It probably is.
3. The "developer" changes the file at the link resolution, or the link is hijacked.
4. The file is accessed in real time, without download or notice through iTunes update!!
4. Said file is accessed by other apps
5. Mayhem ensues - in this case, an accidental denial of service attack

It takes little imagination to postulate what imaginative hackers can come up with.

Appalling!

item

MacInTouch

Apple's fruitless rootless security broken by code that fits in a tweet

Earlier this month, Apple squashed a logic bug in SIP found by SentinelOne researcher Pedro Vilaça. It could be exploited by software already running on a Mac to bypass Apple's SIP defenses, rendering the safeguards useless. Vilaça demonstrated at the SyScan conference the design weakness using GDB to modify and create files in /System as a normal root user.

However, flaws within SIP remain. One problem is that just like bugs lingered in root-owned setuid binaries that were exploited by hackers, flaws present in SIP-entitled programs can be abused, too.

Stefan Esser of German security biz SektionEins also gave a talk at this year's SyScan during which he highlighted a bunch of SIP-related vulnerabilities. Esser told The Register "everything in my slides is unfixed" by Apple in the latest version of OS X except for two flaws: the kas_info syscall and a malicious mount.

item

Davide Guarisco

Re: SIP vulnerabilities

The truly excellent presentation by Stefan Esser demonstrates how to disable SIP without the need to reboot from a recovery partition (you still have to restart the computer).

item

MacInTouch

Apple is now collecting some medical data from iPhones. Here's why

When Apple launched ResearchKit more than a year ago, the promise was to allow people from all over the world to participate in studies for medical research via iPhones and other Apple devices. At the time, the company made clear it was not in the business of collecting medical and research data from users -- that was between the subjects and the researcher (mostly hospitals and universities).

Now that's changing.

Two apps have updated their fine-print details to include Apple itself as a "secondary" researcher. Mole Mapper, an app from Oregon Health & Science University that tracks skin moles to help prevent melanoma, and the mPower Research App for Parkinson's now list the tech giant as a third party that can receive medical data from study participants.

item

Al Varnell

Davide Guarisco wrote about SIP vulnerabilities

The truly excellent presentation by Stefan Esser

I'll allow that it can be called an excellent presentation, but I have no respect for people like Stefan that reveal vulnerabilities publicly without making any attempt to let Apple know about them in advance.

Of course Apple could help themselves in this area by offering a bounty to individuals that do let them know first.

item

MacInTouch

Weakness in iOS enterprise hooks could let bad apps sneak in

Security researchers at Check Point Software claim to have found a weakness in Apple's mobile device management (MDM) interface for iOS devices that could be exploited to gain complete access to devices. Dubbed "SideStepper," the approach could allow an attacker to hijack enterprise management functions and bypass Apple's application security.

By sending a link to a victim's device, someone could take control of the MDM software on the phone and push potentially malicious applications to the device as well as perform other configuration changes as a remote administrator. While Apple's security screening for the applications it allows into its App Store is rigorous, there is a backdoor left in the screening process: enterprise app stores. And new research by Check Point being presented at Black Hat Asia shows that even with security improvements in iOS 9, attackers can kick that backdoor in by hijacking the enterprise management connection.

New SideStepper attack targets corporate iOS device managers

Apple's security concessions in corporate devices may have created a loophole in an otherwise secure system, according to new research from Check Point Software Technologies, a company that sells internet security hardware and software. When successful, this "SideStepper" attack gives perpetrators access to victims' devices, including their data, as well as the power to install malicious apps. The new attack takes advantage of less rigorous software controls for corporate device users, particularly those who use Mobile Device Management solutions (or MDMs) to get apps delivered to their phones.

The majority of device owners aren't susceptible to the attack because they don't use MDMs. Even those who do, have to fall for a phishing text message, and then ignore security warnings about the malicious download. Though the attack is hard to pull off, SideStepper shows how common corporate practices can open the door to otherwise impossible iOS attacks. Successful attackers gain unprecedented powers, allowing them to masquerade as the device's manager and control it remotely.

Unpatched stealthy iOS MDM hack spells ruin for Apple tech enterprises

Enterprises the world over are at risk from a seamless new attack that allows the latest Apple devices to be quietly compromised in what researchers say requires a total overhaul of Cupertino's enterprise provisioning architecture for mobile device management.

The unpatched hack - dubbed SideStepper and crafted by Israel-based Check Point hackers Ohad Bobrov and Avi Bashan - begins with a near-perfect phishing attack targeted at staff, and ends with complete compromise of fully updated iOS devices running version

It takes advantage of Apple's newly streamlined enterprise provisioning architecture, which allows tech shops to install non-App Store applications on staff handsets.

Mobile device management of Apple devices is a system used by almost all Fortune companies and scores more enterprises. Almost all are at risk of the attack, the pair told The Register.

item

Davide Guarisco

Al Varnell has

"no respect for people like Stefan that reveal vulnerabilities publicly without making any attempt to let Apple know about them in advance."

Contrary to Al, I have plenty of respect for security researchers who publicly disclose vulnerabilities (instead of selling them for a profit, or worse). The world is safer because of the work of people like them, who forced powerful corporations to take security seriously by holding them accountable.

Public disclosure is key, see this essay by Bruce Schneier:

Full Disclosure of Security Vulnerabilities a 'Damned Good Idea'

Shall a person who comes across a vulnerability first inform the company and give them a chance to fix it? IMHO, it depends on the kind of vulnerability. Also note that this so-called "responsible disclosure" raises some thorny issues, like deciding what constitutes an appropriate waiting period, dealing with often deaf or outright hostile companies, etc.

It's not clear to me whether Al, in singling out Stefan, refers to the current SIP vulnerability disclosure or previous disclosures. If it's the SIP, IMHO no disclosure to Apple would be morally necessary, as disabling SIP does not per se make a Mac less secure.

Furthermore, the following interesting details emerge from Stefan's presentation:

1. (p. 62) One of the vulnerabilities has been reported to Apple one year ago, but still it was not fixed (reports of unfixed bugs sure sound familiar to MacInTouch readers, but we are talking security flaws here)

2. (p. 65) "somewhen between the 2nd and 3rd fix Apple contacted me by e-mail and asked me to review their fix-too bad they didn't offer bug bounties"

item

Al Varnell

Davide Guarisco writes:

It's not clear to me whether Al, in singling out Stefan, refers to the current SIP vulnerability disclosure or previous disclosures.

It was primarily his previous disclosure of OS X DYLD_PRINT_TO_FILE in July

OS X DYLD_PRINT_TO_FILE Local Privilege Escalation Vulnerability

which resulted in an active exploit in August before Apple could patch it.

0-day bug in fully patched OS X comes under active exploit to bypass password protection

I agree that the SIP vulnerabilities are not nearly as serious, but still follow his pattern of unapologetic public disclosures first. I'm not aware of any other security research agency/researcher that hasn't given Apple a reasonable amount of time to correct an issue, which certainly appears to be the industry best practice.

I accept the argument that Apple isn't as timely or thorough as they need to be in this area, and they have been known to miss deadlines.

item

MacInTouch

Panic over! Apple fixes iPhone 6S lockscreen bug

Presumably, given that this particular programmatic pathway into the Contacts app was impossible before 3D Touch was introduced, it was never identified as a possible security short-cut past the lockscreen, never tested, and never blocked.

But once you'd opened the Contacts app, you could then access the whole contact list, even though you'd started from the lockscreen and never entered the passcode. No update required

The fix turned out to be surprisingly easy, and didn't even require Apple to push out an iOS update. (Just as well, because the latest iOS update, , came out less than a week ago.)

It seems that all Apple had to do to patch against this flaw, or perhaps more accurately to work around it, was to reconfigure Siri not to process "open Twitter" commands from the lockscreen.

Even though this trick no longer works, Siri remains a liability on your lockscreen, and so we very strongly recommend that you don't allow it.

item

MacInTouch

New Threat Can Auto-Brick Apple Devices

If you use an Apple iPhone, iPad or other iDevice, now would be an excellent time to ensure that the machine is running the latest version of Apple's mobile operating system -- version Failing to do so could expose your devices to automated threats capable of rendering them unresponsive and perhaps forever useless.

On Feb. 11, , researcher Zach Straley posted a Youtube video exposing his startling and bizarrely simple discovery: Manually setting the date of your iPhone or iPad all the back to January. 1, will permanently brick the device (don't try this at home, or against frenemies!).

Now that Apple has patched the flaw that Straley exploited with his fingers, researchers say they've proven how easy it would be to automate the attack over a network, so that potential victims would need only to wander within range of a hostile wireless network to have their pricey Apple devices turned into useless bricks.

item

MacInTouch

U.S. agency advises Windows PC users remove Apple's QuickTime over bugs

The U.S. government has recommended that Windows PC users uninstall Apple Inc's QuickTime video player after security software maker Trend Micro Inc said on Thursday it had discovered two new bugs in the software. [] Trend Micro said that it did not know of any cases where the bugs had been exploited by attackers, but urged Windows users to immediately uninstall it because Apple was phasing out the program, which means it will not fix the bugs.

item

MacInTouch

Apple says it has the 'most effective security organization in the world'

Apple said in a press briefing earlier today that it has the "most effective security organization in the world," and discussed multiple layers of iPhone security on both the hardware and software side to underscore this point.

The press briefing with Apple engineers was highly technical, including details that were previously undisclosed and in some cases might require deep knowledge of security protocol to understand. But it doesn't take a degree in CS to understand the timing and relevance of the briefing: Apple is currently at odds with the U.S. government over the issue of encryption. While the government is exerting pressure on Apple to make the iPhone less secure and to cooperate when it comes to obtaining crucial digital information, the company is adamant that doing so would compromise the privacy and security of consumers.

item

William Timberman

I turned on iCloud's two-step verification some time ago, including creating application-specific passwords where appropriate. Apple has now replaced this (as far as I can tell) with a newer version, which they're calling two-factor authentication.

This newer version seems to offer additional convenience and security benefits, such as doing away with the need for application specific passwords, and sending six-digit rather than four-digit authentication codes to our trusted devices.

My question is this: must I turn off two-step verification before I can activate the newer two-factor authentication? The person I spoke to at Apple support thought that this was what I had to do, but he wasn't sure -- apparently the changeover is too new for any specific documentation to be available on switching from one to another.

Since I'm running El Capitan on my iMac, and iOS on my trusted device (an iPhone 6S Plus), I should be eligible to use the later version, but how to make the changeover isn't at all clear to me, and I don't want to risk bunging up what I've got now until I can get more information. Does anyone here know what's up?

item

MacInTouch

US-CERT to Windows Users: Dump Apple Quicktime

Microsoft Windows users who still have Apple Quicktime installed should ditch the program now that Apple has stopped shipping security updates for it, warns the Department of Homeland Security's U.S. Computer Emergency Readiness Team (US-CERT). The advice came just as researchers are reporting two new critical security holes in Quicktime that likely won't be patched.

item

Jay Gardinar

Macintouch:

Apple says it has the 'most effective security organization in the world'

Apple said in a press briefing earlier today that it has the "most effective security organization in the world," and discussed multiple layers of iPhone security on both the hardware and software side to underscore this point.

aaaannnd then there's this:

Rogue Source Code Repos Can Compromise Mac Security Due to Old Git Version

Recent Mac versions come bundled with a very old version of Git () that is vulnerable to two security flaws that allow attackers to execute code on the device when the user forks a Git repo holding "malicious" code. The problem is that users can't upgrade this Git repo, they can't change its runtime permissions, nor can they remove it because Apple blocks even root users from twiddling with some system-level programs. "If you rely on machines like this, I am truly sorry. I feel for you," the researcher wrote on her blog. "I wrote this post in an attempt to goad them [Apple] into action because this is affecting lots of people who are important to me. They are basically screwed until Apple deigns to deliver a patched git unto them."

SIP FTW! (For the hackers at least.)

item

Michael Cashwell

For the audience in question this [article] seems overblown.

Anyone using git is likely a software developer and it's trivial for such a user to install a package manager like Homebrew and have the latest git at their fingertips. My git version is and I barely have to lift a finger to keep it up to date.

Apple should do better, yes, but it's not hard to free oneself from any dependency on them for open source software.

[Not sure if you read the whole article, but I'll append a relevant quote below. -Ric Ford]

"If you rely on machines like this, I am truly sorry. I feel for you," Mrs. Kroll wrote on her blog. "I wrote this post in an attempt to goad them [Apple] into action because this is affecting lots of people who are important to me. They are basically screwed until Apple deigns to deliver a patched git unto them."

It is worth mentioning that users can always choose to install their own version of Git on top of the built-in system, but the vulnerable version will always remain, exposing users to attacks. Furthermore, some apps come with a harcoded Git path that leads to "/usr/bin/git", and so, users might use the older vulnerable version without even knowing it.

item

David McLaughlin

Use the git OS X client Tower and use the app's internal version of git.

You can also use Homebrew to install a newer version of git, which can also be used by Tower via a quick preference change.

item

MacInTouch Reader

With my Mac, the version of GIT that comes with it is I'm running El Capitan

item

Wire

Re vulnerable Git:

I used updated Git via Macports and struggled with it because the way PATH works on OS X was unexpected, and sometimes the Apple built-in Git is invoked, leading to errors and confusion. Similar struggles with complex packages like Ruby and MySQL.

Unix-style development on a Mac is a black art, because OS X is structured very differently than other *nixes. Apple provides various point-in-time versions of open-source-software which have been tailored to OS X idiosyncracies and which cannot be updated. Plus applications can bring their own distributions along, for example Cyberduck FTP client, which I think brings its own Java VM along in its package. Teasing apart interactions between Macports / Homebrew, OS X Frameworks, and OS X apps is tricky.

For entertainment of the diligent reader, I suggest updating OS X bash to a later version.

It's not a big deal, but my point is Homebrew / Macports are not a trivial option, first to learn and understand, operation, and then incurring their own burdens of maintenance above and beyond OS X admin.

So I don't see how the OS X Git exploit debacle can be waved away by tossing in Git via Homebrew.

item

Eric Hildum

Unix development on OS X is not that different than traditional Unix. I suspect that reader Wire is not familiar with just how much variation in Unix environments there really is/was over the years. Even now, Linux - which I suspect is what Wired is really familiar with - is significantly different that Unix in either the ATT or BSD flavors.

Apple's attempts to maintain compatibility also suffer from the changes made in Gnu licensing which were designed to make it difficult for commercial firms to use the software without releasing their patent portfolio. Thus, you will never find any software licensed under GPL v3 on any commercial product made in the US or most of Europe unless the company has no patents of any value. (You will find commercial products in China and other countries lacking in strong IP protection, but they will not be made available elsewhere.)

As a commercial software developer having had to deal with licensing issues, I too have to go to great lengths to ensure that no product developed contains anything with an adverse license. The risk to shareholders from some of these licenses - by design - is too great to allow them anywhere near a commercial product. I have had products held up for months attempting to resolve licensing issues, and the cost to ensure that a product can be safely shipped is significant - I have to scan every line of code of every build - and this does affect the end user licensing cost.

item

MacInTouch Reader

Just to confirm Ric's post from Thursday, April 28, on Apple blocking yet another version of Adobe Flash, Apple has updated XProtect to Version

item

MacInTouch Reader

William Timberman asked a while ago

'My question is this: must I turn off two-step verification before I can activate the newer two-factor authentication'

Yes, from everything I've read, the old must be disabled before the new and better (?) is enabled:

"Two-factor authentication can only be enabled from a compatible Apple device (iOS 9, El Capitan). If two-step verification is already enabled, it must be first disabled in order to enable two-factor authentication"

The Elcomsoft link has a very detailed overview of the two. It also talks about their hacking tool, so that raises other questions.

manicapital.com
manicapital.com
manicapital.com

My question is, is it really better or safer to upgrade to it? The only advantage I can see is that you get to see on a map where the request is coming from, and that Apple will actually help you recover lost accounts with the new 2-Factor because they don't use Recovery Keys anymore.

Apple says it's more streamlined, but rather than choosing which trusted device you want your security code sent to, Apple now apparently spams all your devices with the security code. Great, so I've setup everyone's phone in my family as a backup trusted phone, they'll all be spammed and interrupted? I'm not sure if each of those devices will have the option to deny access, but I could see that running into all sorts of problems.

item

David Charlap

Eric Hildum wrote:

"Unix development on OS X is not that different than traditional Unix. I suspect that reader Wire is not familiar with just how much variation in Unix environments there really is/was over the years "

This brings me back to my early days of software development in the 90's. Trying to write portable software for the UNIX platform was quite a challenge.

There was a POSIX standard, but very few systems were fully compliant, and several popular systems were not compliant at all. Between SunOS, Solaris (SunOS version 5 and later), HP-UX, SGI Irix, DG-UX, IBM AIX, DEC Ultrix, and a wide array of "micro" versions for PCs - Xenix, SCO, several different BSDs and the then-fledgeling Linux, it was quite a challenge to develop software that could be compiled and run properly on all of them. Special-case code in libraries and running test suites on every single supported OS was mandatory.

Some things we had to deal with included: C compilers not fully ISO compliant (even though C had an ISO standard since , there were still popular non-compliant ones even in the late 90's), not all systems used POSIX-standard headers - so you would need to include different "standard" headers on different platforms. "Standard" APIs sometimes required extra parameters or would return non-standard error codes. Some standard APIs simply behaved differently, despite having the same name and parameters and return codes as the POSIX standard.

And then there's the nightmare of X11 graphics. The lowest-layer "xlib" graphics is pretty standard, but every window manager mucks with it in different and mutually incompatible ways. For instance, when you position a window at coordinates (x,y), does that point represent the upper-left corner of the window's frame or the upper-left corner of its content area? When you set a window's size to a particular height/width, does that include the frame or not? Different window managers do this differently. So you need to compensate by adding/subtracting the sizes of the various "decorations" that comprise the frame. But how do you know what the sizes of those decorations actually are? There was (and in many cases, still is) no standard way to find out, so you need to look for lots of hints in the system and then hope and pray your customer isn't using a window manager you didn't know about when you did your testing.

These days, many of those issues are no longer problems, because most UNIX systems either no longer exist or have become more compliant to the POSIX (or SUS) standards, and most people use either GNOME or KDE for their desktop environments (and the other popular ones tend to conform to their standards), but there are still some major differences between those platforms that comply mostly with BSD (like Mac OS X) and those that comply mostly with SysV (like Linux).

"Apple's attempts to maintain compatibility also suffer from the changes made in Gnu licensing which were designed to make it difficult for commercial firms to use the software without releasing their patent portfolio. "

Yes. Which is why you will notice that XCode is no longer based on the GCC compiler, but is instead based on clang, which has a much more commercially-acceptable open source license.

I personally find it incredible that so many corporations embed Linux in commercial products, given the massive legal encumbrances that go along with any software licensed under the GPL. Especially when they could just as easily use a BSD variant of UNIX, whose licenses are nowhere near as restrictive.

item

John Grout

The popular top-down parser generator ANTLR was rewritten from scratch in its version 3 to clear its entanglement with anti-business user licenses.

My employer is growing concerned enough to consider barring the installation and use of GPL V3 tools on their systems the standard had been to not ship code that installed or contained GPL software. It would be sad if Stallman allowed his hatred of capitalism to drive his great gift to the development community into the same irrelevance as the original, capitalism-free GNU C++ compiler (like much of Linux, the development of the current GNU C++ compiler is funded by support contracts voluntarily entered into by businesses).

item

Wire

Re Eric Hildum and Unix variations:

My point was about another reader's admonition that a security-vulnerable older version of the Git change control package, which comes with OS X, can be remedied by using Homebrew to install a later version. My point was that even within the narrow confines of OS X Darwin vs Linux, much less the vast space of Unix and unixy software - I do have some awareness of incredibly huge that space is - the way that OS X is organized truly is its own branch of the Unix tree, so I completely agree with Eric Hildum on variation.

Even popular packages such as LAMP-style stuff, which are well-ported and allow work at high-levels of modular work, free of details of the underlying OS, have tricky installation and admin details on OS X, and in my experience, the trick is keeping sorted out what tool you're actually using. I have been quite surprised to find that using an updated version of Git under an updated version of bash installed via Macports, where I'd set Terminal and PATH and various evironment variables to how software is located, that an OS X supplied part of Git was still getting run from the Mac default /usr/bin, and this was breaking Git in weird ways.

The orginal post said that an old security-vulnerable version of Git in OS X is no big deal because if you care, you can just install a later version on your own via Homebrew. I'm pushing back on this idea. It's not that simple, precisely because of variations of O SX from Linux. Moreover, working with Homebrew and Macports adds admin complexity, increasing the burden of support.

Again, re Eric Hildum, my point had no consideration of the nightmare hell which is the history of Unix licensing, though I agree everybody should be aware of it and the record, which shows that it was so bad that an MIT grad student named Stallman and later a Finnish high-school student named Torvalds devoted their entire lives to helping the world overcome the nastiness known as the Unix Wars that Eric Hildum decries, and we collectively owe them a vast debt of gratitude.

Apple, in spite of its mission to Think Different, has, to my knowledge, offered little to this software-world-changing paradigm. But Jobs had the savvy to partake of the Unix-world to build Next, and that's why we're even talking about OS X and Unix, and "that ain't bad" (as Jack Nicholson playing the President in Mars Attacks noted to the American people about still having 2 out of 3 branches of the Federal Government after Martians wasted Congress.)

item

William Timberman

[Re about Apple two-factor vs. Apple two-step authentication]

Thanks very much -- this was exactly the info I was looking for. The Elcomsoft article in particular did the trick. I'm going to have a bash at replacing the old with the new today, and will report back on my experience.

item

Eric Hildum

Actually, I hope Stallman's anti-corporate attitude drives the nails in the Gnu C compiler's coffin. I am very tired of having to deal with applications written in Gnu C that cannot be compiled with any standards compliant compiler, all of which generate far better code and generally offer better error messages and debugging environments.

There are far too many people who are simply not aware that Gnu C is not any form of C, and blithely program themselves into a compiler corner. Just try turning on any of the standards compliance flags when compiling, and you will see what I mean.

item

MacInTouch Reader

Re

See Mavericks Security Update

Old news??

[See, e.g. &#;"Apple Failed to Patch Rootpipe Mac OS X Yosemite Vulnerability."&#; It appears that Apple patched the vulnerability with the security update after failing to patch it with its first attempt. However, a careful reading of Apple's &#;"About the security content of OS X Yosemite v and Security Update "&#; shows some patches listed solely for OS X and not for OS X (e.g. CVE, among others, such as CVE, CVE through CVE, etc.). -Ric Ford]

It does mention an update to the "Admin Framework" (whatever that is) available for Mavericks as well as Yosemite, but they're not links. In fact I can't identify any links to what they're referring to. (Hey, Apple, what is this, a treasure hunt?)

Two questions:

Is the "Admin Framework" referring to the same RootPipe vulnerability that Ric linked to?

If so, where is the updater downloadable from?

item

MacInTouch

Lists of available trusted root certificates in OS X

The OS X Trust Store contains trusted root certificates that are preinstalled with OS X. About trust and certificates

Each OS X Trust Store listed below contains three categories of certificates:

• Trusted certificates establish a chain of trust that verifies other certificates signed by the trusted roots--for example, to establish a secure connection to a web server. When IT administrators create Configuration Profiles for OS X, these trusted root certificates don't need to be included.
• Always Ask certificates are untrusted but not blocked. When one of these certificates is used, you'll be prompted to choose whether or not to trust it.
• Blocked certificates are believed to be compromised and will never be trusted.

OS X Trust Store

item

David Empson

Apple has released Xcode (which requires OS X ). It includes an updated version of git which fixes the known security issues recently discussed here.

manicapital.com

Git

Available for: OS X El Capitan v and later

Impact: A remote attacker may be able to execute arbitrary code

Description: A heap-based buffer overflow issue existed in the
handling of filenames. This issue was addressed by updating git to
version

CVE-ID
CVE&#;&#;
CVE&#;&#;

item

MacInTouch Reader

Thanks, Ric, for the details on Quicktime for Windows vulnerabilities before version On El Capitan, I have also installed Quicktime , because it has editing features lacking from the current version. Obviously there are no issues with my self-made movies, and Quicktime is the default player for third-party movies. But have I made Quicktime vulnerable via libraries that Quicktime installed? Probably not, but I wonder.

I also wonder if in OS X , if Quicktime will go away completely. I'd hate to think of life with nothing but one solution -- VLC -- even though that's a great program.

And on a totally different subject, should we be worried that none of Apple's Airport routers have received firmware security updates in years?

item

David Charlap

An anonymous MacInTouch reader wrote:

"Thanks, Ric, for the details on Quicktime for Windows vulnerabilities before version On El Capitan, I have also installed Quicktime , because it has editing features lacking from the current version. Obviously there are no issues with my self-made movies, and Quicktime is the default player for third-party movies. But have I made Quicktime vulnerable via libraries that Quicktime installed?"

It is important to keep in mind that QuickTime is Apple's trademark for the entire gamut of media-playback APIs [application programming interfaces] in Mac OS. On a Mac, the QuickTime Player app is a (fairly thin) wrapper around these APIs.

The fact that they are no longer developing QuickTime for Windows doesn't mean they aren't developing the QuickTime APIs for Mac OS X.

If you are concerned about security, you can disable the QuickTime plugin in your web browser (I don't know if there still exists one - my Mac isn't with me right now).

As for the version numbers, I don't think Apple is actually distributing the QuickTime version 7 APIs. When you run the QT7 player, I think it's a back-port of the player application, but is using the same QT APIs that the QT10 player uses for its back-end.

(Can anyone with more technical expertise here confirm or refute this? I think I'm right, but I'm not % certain of that.)

item

James Cutler

In article , a MacInTouch reader asked

should we be worried that none of Apple's Airport routers have received firmware security updates in years?

How many years? Two, twenty, or what? Maybe there were no security faults discovered in "years". On the other hand, many security mavens would consider the current absence of SNMP and logging support to be security enhancements, in that both can be information leaks, and SNMP can easily be used by malware for misconfiguration. Not to mention that the code may be more stable and maintainable with the reduced feature set.

Maybe Apple has just not bothered to inform us in this area. It is not unusual for Apple not to communicate much technical data about changes, either before or after the changes occurred.

item

MacInTouch Reader

James Cutler in asked how many years since Airport routers received firmware security updates, and said,

"Maybe Apple has just not bothered to inform us in this area."

It has been about 3 years for the Airport Express, and for the Airport Extreme:

Airport Extreme n, 5th gen, released Aug. 13,
Airport Extreme ac, released Apr. 22,

All in all, between two and three years without firmware security updates, or even OS compatibility updates, even for the latest model.

We all know Apple is perfect, so there's no need to worry right? Beyond potential security issues, Apple ignores certain products, and maybe the Airport is being ignored.

item

Scott Bayes

David Charlap asks:

As for the version numbers, I don't think Apple is actually distributing the QuickTime version 7 APIs. When you run the QT7 player, I think it's a back-port of the player application, but is using the same QT APIs that the QT10 player uses for its back-end.
(Can anyone with more technical expertise here confirm or refute this? I think I'm right, but I'm not % certain of that.)

TL;DR: probably they use different libraries. So classic QT vulnerabilities shouldn't affect new-age stuff, except where new libraries may have copy-pasted from old code.

My nm-fu is rusty, but a quick of binaries of both apps (classic QTPlayer 7 and new version) on shows almost no library symbols containing upper- or lower-case "qt" common to both apps. Lots of symbols even after grep-ing, so I may have missed something, but it looks like the new app uses a whole different library. The classic app uses a ton of QT symbols, and they look like the classic library should look (spoken from partial ignorance) IMNSHO.

Had a slight panic attack when I couldn't find my "Pro"-registered QT player 7 in /Applications (including on my backups), but found I had squirreled it away in /Applications/Utilities. Phew!

item

MacInTouch

Gunfight at the iOS corral as Apple releases but bans jailbreak detector app

Apple famously doesn't allow proper anti-virus software in the App Store, a restriction that applies to OS X as well as to iOS software.

The limitations imposed on submissions pretty much make third-party threat prevention software, such as a real-time anti-virus, a technical impossibility in the App Store.

Fortunately, on OS X, you can install software from outside the App Store - by default from trusted developers, and, by changing a system setting, from anyone you like.

On iOS, where it's the App Store or nothing, you're out of luck.

item

Joe F

It has been about 3 years for the Airport Express, and for the Airport Extreme:
  Airport Extreme n, 5th gen, released Aug. 13,
  Airport Extreme ac, released Apr. 22,

All in all, between two and three years without firmware security updates, or even OS compatibility updates, even for the latest model.

We all know Apple is perfect, so there's no need to worry right? Beyond potential security issues, Apple ignores certain products, and maybe the Airport is being ignored.

Or could it be that Apple's routers are so limited (crippled?) that there aren't any good attack vectors to get into them? I'm sure there are vulnerabilities, but to the same degree as a fully configurable router that has web access to alter settings? Even Apple's own, dedicated configuration app, Airport Utility, is far, far less capable than previous versions.

Are there any methods other than Airport Utility for altering the settings or updating the firmware on an Apple router that could be used as an attack vector?

item

Bo Clawson

I periodically get requests from Apple to access my Airport Time Capsule. I always allow it and just assumed it was issuing updates.

Am I wrong?

item

W. Keith McManus

Since the previous iPad update, one curious thing happens. On start up all things seem OK. When I try to enter my passcode, nothing happens. I have tried a number of times just to let the iPad be and see if it finally allows access, nothing. By pressing the power switch several times the screen goes black, then the display showing passcode request appears. This time the iPad accepts passcode. After that all operations seem to work as advertised.

item

MacInTouch Reader

Joe F writes,

"Or could it be that Apple's routers are so limited (crippled?) that there aren't any good attack vectors to get into them?"

It's not that Airport routers are limited, but that Airport routers don't use a web interface. Their firmware requires using Apple's Airport Utility, not a web browser as with every other router, so any exploits will be very different.

item

Bill Martin

"By pressing the power switch several times the screen goes black, then the display showing passcode request appears. This time the iPad accepts passcode. After that all operations seem to work as advertised."

Take it to the AppleStore or call Applecare and get that thing fixed or replaced.
Do not Stop. Go.