Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft, Once Infested with Security Flaws, Does an About-Face

nytimes.com

Post reply on HN
Print view View original

121–130 of 185 posts

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#121

Post by cmdrfred »

TeMPOraL wrote: post #83
Rafert wrote: post #63

Earlier quoted context omitted.

Which was caused in part by badly behaving programs (writing user data to the Program Files directory) that triggered the UAC prompt, if I'm not mistaken.

They improved the system in the next release, and since Win7 UAC generally works perfectly even with the "badly behaving" software. Sensitive directories are now mirrored elsewhere in the filesystem, so that when your program wants to read from, say, Program Files directly, what it really reads is C:/Users/[username]/AppData/Local/VirtualStore/...

I've never experienced this in writing my own software. If I try to read or write to a directory I'm not allow to I simply get access denied.

f = open('C:/windows/test.txt')

try:

    f.write('test')
except Exception as ex:

    print ex
IOError: [Errno 13] Permission denied: 'C:/windows'

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#122

Post by Sanddancer »

ChuckMcM wrote: post #57
tptacek wrote: post #7

This is a weird story, since professional security people would have told you the same thing back in 2007. Windows wasn't originally designed to be secure. Even NT, which is a serious multi-user kernel, was a product of 1990s C programming style. And while that's true of the Unices of the time as well, none of them had Microsoft's absurd user base, and so none of them had the same terrible malware incentives. This al…

Not that weird. Illustrative perhaps. So you and I would have agreed in 2007 that Windows was much better at security than they had been, but we are both pretty tightly connected to the technology market. Today, 8 years later, my Mom and Dad think Windows is a "secure" system as they haven't had any issues for long enough that their opinion of it has changed. The final leg of this journey will be when Windows + Windo…

In Android, Google's stuck between a rock and a hard place because so much of the distribution is handled by the downstream vendors. Were I google in setting up the distribution agreements, I'd be much more strict on the requirement for getting Google services on the phone, like reasonable minimum security support periods. I'd also make it easier for vendors to be able to agree to such things, by promising support on their end for a reasonable amount of time, and preferably, a stable kernel-level abi so that they don't need to do as extensive regression testing when a kernel-level patch needs released.

Android development feels a lot like current web development plans, where things are released, and not a lot of thought is given to backward compatibility and backporting security. Google needs to tighten those reins a bit, either by pushing handset developers forward faster and/or giving reasonable support for older devices themselves.

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#123

Post by blinkingled »

btilly wrote: post #117
blinkingled wrote: post #103

Earlier quoted context omitted.

No it isn't - if your app did not ask for say a permission to connect to Internet or get a list of apps - there is no way to do that using reflection or NDK or whatever.

I don't know about the latest version of iOS, but your statement was certainly wrong just 2 years ago. See https://www.usenix.org/system/files/conference/usenixsecurit... for details of how to write an app that bypasses App Store review but will have security holes that allow your app to access APIs at runtime with no notification that it was not supposed to have access to.

Yes, that was exactly my point. People keep repeating the iOS security being fundamentally better marketing mantra but it has been ordinary although the closed system helps it somewhat and they did seem to get the fingerprint security right. And I was referring to Android's permissions model when I said no you can't bypass it.

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#124

Post by millstone »

blinkingled wrote: post #120
millstone wrote: post #119

Earlier quoted context omitted.

> write an app that does that Here's a sample of how to invoke `Activity.savedDialogKeyFor`, which is private: Method privateMethod = Activity.class.getDeclaredMethod("savedDialogKeyFor", int.class); privateMethod.setAccessible(true); String result = (String)privateMethod.invoke(this, 42); System.out.println("Got result: " + result); Worked perfectly on Android Marshmallow emulator. As I said, it's trivial. > Also -…

You're confusing accessing private methods with violating the Android permissions model. Two totally separate things. Edit: Also my larger point was the iOS security is not fundamentally better than anything else. The closed nature, restrictive policies etc. help but fundamentally it's nothing outstanding. It was a response to tptacek claiming opposite.

I am not confused. Please reread the thread.

You asserted that iOS is "unfixable" because the ObjC runtime cannot prevent apps from using "private/internal calls that your app is not supposed to use," whereas "Android gets code access control for free with Java."

But as I showed, Java access controls are easily bypassed, so they do not provide any security. This is by design: security is enforced at the process boundary, not by the runtime.

My hope is that you now appreciate that neither the ObjC nor Android Java runtimes are a security risk, because they are not responsible for enforcing any security policy.

> Also my larger point was the iOS security is not fundamentally better than anything else

iOS security is fundamentally better. You can read the whitepaper to understand the ways: data protection classes, the Secure Enclave, and lots more.

But here's a damning fact: iOS encrypts your data by default, Android does not. That by itself makes iOS fundamentally more secure.

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#125

Post by ChuckMcM »

Sanddancer wrote: post #122
ChuckMcM wrote: post #57

Earlier quoted context omitted.

Not that weird. Illustrative perhaps. So you and I would have agreed in 2007 that Windows was much better at security than they had been, but we are both pretty tightly connected to the technology market. Today, 8 years later, my Mom and Dad think Windows is a "secure" system as they haven't had any issues for long enough that their opinion of it has changed. The final leg of this journey will be when Windows + Windo…

In Android, Google's stuck between a rock and a hard place because so much of the distribution is handled by the downstream vendors. Were I google in setting up the distribution agreements, I'd be much more strict on the requirement for getting Google services on the phone, like reasonable minimum security support periods. I'd also make it easier for vendors to be able to agree to such things, by promising support on…

I largely agree, and it is the same problem Microsoft faced when downstream OEMs put their OS load on their hardware, adding in their own drivers and "features". Even today people like Lenovo get smacked for adding things like Superfish. But the underlying OS has gotten much more reslient. Anyway, that is why, to me, Google seems a bit like Microsoft in the 2003.

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#126

Post by tptacek »

Justsignedup wrote: post #113
pcwalton wrote: post #76

Earlier quoted context omitted.

> I'm curious why you mention Google though, their security record on Android is a lot worse than either Windows phone or IOS. In many ways I feel like they are exactly Windows in 2003 with regard to "its secure if you use our APIs" kind of security. Chrome (OS)'s security model is a lot better, and compared to Android it was designed more in-house. Android was an acquisition and has more legacy design baggage (thoug…

Android's security is actaully fantastic. The problem is the inability for google to distribute security updates. In 6.0 I now get monthly security updates and there is even a "security update version" of like "november 2015" in the status. The latest junk even made it into Android 4.1 devices for security updates. But that is neither here nor there, the fact that we have 4.1 devices is a problem.

Android's system security design is inferior to that of iOS.

But, iOS's superiority (a) derives in significant part from Apple's total control over the hardware platform†, and (b) comes at the cost of a lot of user control tradeoffs that nerds like us tend to hate.

Really, to suggest that Android's security is at parity with Apple's, you'd have to be arguing that Apple does a terrible job at exploiting their inherent advantages of control over hardware and control over what's allowed to run on the platform. Apple does not do a terrible job at those things.

† Yes, Google controls some of their hardware, but they have an ongoing support requirement for a lot of hardware they have no control over at all, and will have that requirement forever, which limits their options.

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#127

Post by Sanddancer »

loginusername wrote: post #34
raesene4 wrote: post #22

Earlier quoted context omitted.

That's an interesting opinion... what makes you think it's the easiest OS to target? Do you have any data to back up the claim that a modern Windows OS is less secure than it's major competitors (OSX and, in some circumstances, Linux) My feeling would be that Microsoft have done a lot in the security line and have also given a lot back to the security community (their SDL documentation which is freely avaiable for ex…

The "security line" is not simply a question of "doing a lot" and "giving a lot back", ex post facto, or setting an "example" in the "security industry". It also has to do with design goals and priorities. Layer upon layer of cruft, with an OS weighing in at multiple GB, is not a confidence builder in the "security line". It also includes default configurations. There are reasons that so many Windows instances have b…

The reason is exactly why MS has improved their security over the years. One of the things they've done is made automatic updating a mandatory feature of the OS. People can't just lazily turn updates off anymore because they can't be hassled for a 45 second break for their computer to maintain itself. Were these people running Linux, a lot of them would be doing the same thing, with the same results. Windows has a lot of botnetted computers because Windows runs the vast majority of computer systems out there.

The neverending security updates is part of the difficult balance MS has to take between compatibility and security. Fixing a security problem that breaks a buggy program written 20 years ago by a company that no longer exists suddenly becomes a support issue, because there are a lot of people who don't want to hear that they have to upgrade their copy of PrintShop.

MS releases security updates in part because they audit their code, and are making strides to get rid of a lot of the cruft. Windows 10 pulled a lot more services out of kernel space and into user space, for example. They're doing so while being conscientious of user needs, instead of telling the user to just code the fix for older programs themselves.

In your small OS, who do you go to for support if something breaks? Who will you go to for support when a program from today breaks ten years from now? These are responsibilities many open source programmers will slough onto the end user, while they're working on the Latest and Greatest PulseConsoleSystemAudioKitD.

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#128

Post by Sanddancer »

wdmeldon wrote: post #20
headmelted wrote: post #10

Earlier quoted context omitted.

Windows 8 was great if you went straight to the desktop and never looked back. There were some terrific upgrades to the classic desktop (even the task manager got real-time graphs and proper hierarchies for the first time). I always pictured a really talented dev team somewhere in Redmond plugging away thanklessly on things that the powers that be thought no-one cared about (like security and usability) until one day…

Very true. But every time I pressed the Windows key to open an application, I was reminded of the horrors that lurked outside of the desktop.

Aye, but it got me really good at just typing the program name I wanted, instead of having to go poking through that pain in the ass menu.

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#129

Post by millstone »

blinkingled wrote: post #123
btilly wrote: post #117

Earlier quoted context omitted.

I don't know about the latest version of iOS, but your statement was certainly wrong just 2 years ago. See https://www.usenix.org/system/files/conference/usenixsecurit... for details of how to write an app that bypasses App Store review but will have security holes that allow your app to access APIs at runtime with no notification that it was not supposed to have access to.

Yes, that was exactly my point. People keep repeating the iOS security being fundamentally better marketing mantra but it has been ordinary although the closed system helps it somewhat and they did seem to get the fingerprint security right. And I was referring to Android's permissions model when I said no you can't bypass it.

You may think it's "marketing mantra" if you're unaware of the technical differences. But compare, say, Apple's Secure Enclave with Host Card Emulation. Apple's design is just more secure. http://www.tomshardware.com/news/host-card-emulation-secure-...

I certainly don't understand characterizing iOS's security model as "ordinary." For example, it encrypts using a separate coprocessor running an entirely separate OS, that is protected against even an iOS kernel exploit. That's definitely not an ordinary design!

Re: Microsoft, Once Infested with Security Flaws, Does an About-Face

#130

Post by blinkingled »

millstone wrote: post #124
blinkingled wrote: post #120

Earlier quoted context omitted.

You're confusing accessing private methods with violating the Android permissions model. Two totally separate things. Edit: Also my larger point was the iOS security is not fundamentally better than anything else. The closed nature, restrictive policies etc. help but fundamentally it's nothing outstanding. It was a response to tptacek claiming opposite.

I am not confused. Please reread the thread. You asserted that iOS is "unfixable" because the ObjC runtime cannot prevent apps from using "private/internal calls that your app is not supposed to use," whereas "Android gets code access control for free with Java." But as I showed, Java access controls are easily bypassed, so they do not provide any security. This is by design: security is enforced at the process bound…

You should really read this Usenix paper - https://www.usenix.org/system/files/conference/usenixsecurit... .

What you are not understanding or ignoring is that iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses by reverse engineering the names of the private APIs and using message passing. Android sure has private APIs and you can access those but you're still restricted to the permissions you asked for. For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently where they rely on manual review to ensure you are not calling the Private API - which fails as can be seen in the Chinese AD SDK fiasco I posted.

So no Android runtime isn't a security risk as much as iOS private APIs are - your app gets a broad set of permissions on iOS by default and you can do clever trickery to call private APIs to collect personal info and who knows what else without the user knowing. Android needs your app to ask for that permission first (and at runtime on M)- you aren't calling a private method on Android without declaring the necessary permission to get what you want without user interaction.

Post reply on HN