What the Daily WTF?

Excel is pretty much a general purpose programming platform for many.

Well, they're wrong. It's a fucking spreadsheet application! Not a RDBMS or GUI framework! The fact you can do something doesn't mean anyone should ever, ever even try to!

And distinguishing "malicious virus removing your documents" vs. "someone wrote a file manager in Excel" is worse than halting problem.

I'd be very glad if they disallowed making file managers in Excel. Principle of Least Astonishment: when I open an Excel spreadsheet, I expect to see an Excel spreadsheet and not a fucking Total Commander.

Besides, you're still asked to run the scripts. If you don't want to, just don't run it.

Here's another halting problem: how can I know if I want to run a script? (Let's assume I can't read the source code.)

I'll be sure to tell everyone you don't think they should be able to do mail merge from another application

If the application in question is Powerpoint, they shouldn't.

or have a spreadsheet that pulls data from a database

Pull? Of course. Push? Hell no.

Here's the thing--making it work without removing the functionality Office et al users have taken for granted for 20+ years, that's probably not just hard, but really hard.

The very thought we live in a world that removing ability to delete arbitrary files from within Excel spreadsheet script will break any application anywhere in the world makes me shiver. Because that means someone actually did that.

anonymous234

I'll be sure to tell everyone you don't think they should be able to do mail merge from another application, or have a spreadsheet that pulls data from a database, any longer.

Not without an explicit "yes, I want to give this script access to my computer" dialog, obviously.

OK, time for a recap. I think people are mixing up two concepts here:

Scripting that can be used to make interactive documents, but not to alter anything else in the computer, like Javascript in a webpage. This can be implemented securely (and obviously should be implemented security, if implemented), despite what it would seem from Adobe and Oracle's continuous fuck ups.
Scripting that can alter other things in your computer or access potentially dangerous outside resources. These are as dangerous as any executable, and obviously SHOULD NEVER RUN WITHOUT EXPLICIT PERMISSION (for a company's internal use, it could be "grant permission to all documents signed with this key" to avoid having a dialog every time).

What does MS Office have? The 2nd thing apparently, although it should be more clear from their messages because some people (me) tend to assume it's the first one when you say "macros".

This means there is no need to "figure out what's safe" (and definitely no need to solve the halting problem) because all scripts are unsafe. It's a binary condition, either it does not run at all, or it runs with full permissions.

So back to the topic at hand:

Treating documents from the Internet differently from documents from internal networks or USB drives is a dubious idea. Some would even say it's a bad idea. It might work as an heuristic most of the time, but it's not hard for an attacker to give you a malicious file in an USB drive, of for malware to copy itself to the internal shared drive, so it can't be relied on for any real security.
Apparently the OP and some other people implied that MS Office won't even let you open documents from the internet without "unlocking" them, and that would indeed be completely unreasonable. Thankfully I don't think it's true. It just opens them in "protected view".

Now, this is an important detail: the "protected view" seems to be just an "extra layer" of security, to protect against buffer overflows and other exploits, not the main barrier to running macros. I'm not sure how Office treats files with macros that don't come from the internet (I don't have it installed here), but I'm expecting a sufficiently scary warning message so that most users wouldn't allow them to run.

FrostCat

@anonymous234 said:

Not without an explicit "yes, I want to give this script access to my computer" dialog, obviously.

Sure. Of course, when all your customers upgraded from Office 2003 to 2007 or whatever, and the mail merge functionality of your app suddenly started acting different because Outlook now pops up an "are you sure you want to let some random 3rd-party app send mail" with a 5-second delay, they'll probably be annoyed. (This is an actual example.)

FrostCat

@anonymous234 said:

This means there is no need to "figure out what's safe" (and definitely no need to solve the halting problem) because all scripts are unsafe. It's a binary condition, either it does not run at all, or it runs with full permissions.

Obviously. I am pointing out, though, that since Raymond Chen's time machine hasn't been invented, warnings were added after the fact, and that both inconvenienced users AND broke workflows (e.g., as of Office 2013 (I think) mail merge triggered from a 3rd-party application broke because the security model changed so that Word opened the template in Reading Mode, which is read-only. This requires a code change in the 3rd-party application to explicitly change the mode.)

blakeyrat

It was designed before the internet made file sharing easy.

boomzilla

@Gaska said:

Well, they're wrong. It's a fucking spreadsheet application! Not a RDBMS or GUI framework! The fact you can do something doesn't mean anyone should ever, ever even try to!

It's people getting work done as best they can. Are there better ways? Sure, but probably not available to them. Your irrational attitude is worse than anything they've done.

Gąska

There are people who do early return by throwing exception of type EverythingIsOk. And there are people who write RDBMS in Excel. Both are using the tools they know to achieve the goal and they give the best from themselves to do it well. But no matter how much they're trying, their work is an utter WTF and giant Doing It Wrong™.

accalia

@Gaska said:

EverythingIsOkAwesome

LTFY

sloosecannon

Not a sandbox vulnerability or an app vulnerability and only relevant if you're installing third party stuff.

FrostCat

only relevant if you're installing third party stuff.

"I want to buy a phone computer that lets me do all kinds of neat things, but I don't want to install any apps that didn't come with it?"

That's ignoring the fact that carrier shovelware isn't perfect, either.

sloosecannon

Third party as in not-from-Play-Store third-party

As in downloading and installing random .apks from unknown sources

FrostCat

Third party as in not-from-Play-Store third-party

There have been vulnerabilities in apps that were on the store.

sloosecannon

Doesn't mean Android apps aren't secure.

Magus

YEAH! Insecurity != not secure! NOOBS!

sloosecannon

That's not what I said

Magus

There have been vulnerabilities in apps that were on the store.

Doesn't mean Android apps aren't secure.

That's not what I said

I believe you.

sloosecannon

@Magus said:

I believe you.

Good.

Filed Under: There have been vulnerabilities in Discourse, therefore browsers are insecure.

Magus

There have been vulnerabilities in Discourse, therefore ~~browsers are~~Discourse is insecure.

This is what you said. I know this, because I read the posts involved. You apparently don't even read what you type.

FrostCat

Also, http://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-19997/Google-Android.html

Good.

Pssst--he's lying.

sloosecannon

@Magus said:

@sloosecannon said:
There have been vulnerabilities in Discourse, therefore ~~browsers are~~Discourse is insecure.

This is what you said. I know this, because I read the posts involved. You apparently don't even read what you type.

That's not what I said.

If there's a vulnerability in the Facebook app that allows unauthorized users to steal your login credentials, does that mean all android apps are insecure? No, it doesn't. It means some idiot of a developer did a crappy job. Therefore, the fact that there are vulnerabilities in single apps doesn't mean the whole system is insecure. I can write a vulnerable app very easily if I wanted to. That doesn't say anything about the apps as a whole. Which is what

Doesn't mean Android apps aren't secure.

is about

Rhywden

If there's a vulnerability in the Facebook app that allows unauthorized users to steal your login credentials, does that mean all android apps are insecure? No, it doesn't. It means some idiot of a developer did a crappy job. Therefore, the fact that there are vulnerabilities in single apps doesn't mean the whole system is insecure.

But the whole system can be insecure. Your logic doesn't wash.

Magus

It depends on the vulnerability. If it's just that you can unhide the password, that's an issue with the app. If it's a hole that some apps plug manually, it's absolutely the platform.

sloosecannon

But the whole system can be insecure. Your logic doesn't wash.

So you're saying a system is insecure if it's possible to write an insecure program in it?

Rhywden

@Rhywden said:
But the whole system can be insecure. Your logic doesn't wash.

So you're saying a system is insecure if it's possible to write an insecure program in it?

If the insecure program is able to affect the system, certainly.

TimeBandit

If the insecure program is able to affect the system, certainly.

So, Windows is insecure then

sloosecannon

@sloosecannon said:
@Rhywden said:
But the whole system can be insecure. Your logic doesn't wash.

So you're saying a system is insecure if it's possible to write an insecure program in it?

If the insecure program is able to affect the system, certainly.

Aside from the (very rare) exploit, which is usually actually at the Linux kernel level and patched very quickly, there isn't really a way to affect the system.
Find an example of a system vulnerability on a modern (4.4+) version of Android, executable via an app. It's not gonna be easy to do.

I think there are a few GB vulns that are executable from within an app, and I think there was one for... 4.3 (?), for very specific devices.
But as a whole, they aren't really a concern.

Rhywden

@TimeBandit said:

@Rhywden said:
If the insecure program is able to affect the system, certainly.

So, Windows is insecure then

As is pretty much any other OS.

Rhywden

Aside from the (very rare) exploit, which is usually actually at the Linux kernel level and patched very quickly, there isn't really a way to affect the system.
Find an example of a system vulnerability on a modern (4.4+) version of Android, executable via an app. It's not gonna be easy to do.

But it's possible.

sloosecannon

But it's possible.

Not on a modern system. Or at least, none have been found.

I'm not arguing that the system is perfectly secure. I'm arguing that it's practically secure, as in "sure, maybe there's some really obscure exploit out there, but none have been found and it's not really a concern"

Rhywden

Google Android : Security vulnerabilities, CVEs

Not on a modern system. Or at least, none have been found.

I'm not arguing that the system is perfectly secure. I'm arguing that it's practically secure, as in "sure, maybe there's some really obscure exploit out there, but none have been found and it's not really a concern"

Yeah. "None".

sloosecannon

How many are exploitable from within an app? Installable on the play store? Relevant to the average user? Applicable to the latest version?

Rhywden

How many are exploitable from within an app? Installable on the play store? Relevant to the average user? Applicable to the latest version?

Why on earth should I do your work for you? You are the one claiming that Android is secure. Then prove it.

You claimed that there are NO exploits. I just proved the opposite.

Blog | Tripwire

Here:

All Android versions below 5.0 are still vulnerable.

That includes your precious 4.4

sloosecannon

You are the one claiming it's not. Prove it.

I'm coming from places like xda developers that look for exploits that are practically usable for things like getting root access. I'm telling you right now, there are no practically usable exploits that I'm aware of. But whatever. We're clearly arguing different points, so nobody can win. I'm out. Have fun, and have a

Rhywden

You are the one claiming it's not. Prove it.

English, moron. Do you speak it? Idiot.

A privilege escalation obviously doesn't count for a stupid guy like you, it needs to be a "full root access" scenario. Yeah, changing goal posts and all that.

sloosecannon

English, moron. Do you speak it? Idiot.

?

Whatever, muting now.

Rhywden

Yeah, run away.

sloosecannon

Actually on second thought, not muting, cause the topic's interesting. I'll just ignore any post you make .
But please, continue to make an ass out of yourself getting the last word. That'll get you places. Trust me.

sloosecannon

@brianw13a - You might have a slightly corrupt document, and the download flag is confusing Word. I'd be willing to bet that would be the cause, cause I've never seen that happen to downloads before...

Rhywden

So, let me recap: A vulnerability which lets an app install arbitrary other apps, alter those other apps and generally has free reign on the data of those other apps - that doesn't count as a vulnerability in your book because it doesn't have root?

Yeah, good luck with that.

"Oh, hey, the burglars got the money out of the safe - but at least they weren't able to burn the house down! Isn't that great?"

Ragnax

Like, um, what? Actually having proper access control and not defaulting to admin for the past ten years?

The default user is still a local administrator. The only difference is UAC is turned on by default, which takes away your full administrator powers and puts them behind a consent prompt. Very nice when it was introduced with Windows Vista, but fatally useless under the default setting in Windows 7 and up.

The default UAC setting of Windows 7 and up is to allow all of Microsoft's own system executables to run with full administrator powers without requiring said consent prompt. (This was changed because people hated how the prompt popped up in Vista for every little thing.)

Microsoft's own system executables include the OS task scheduler. The scheduler can be used to register a task that will execute with the full permissions and privileges of the account that registered the task, i.e., the full power of a local administrator. The people that designed it do not re-require explicit consent for such a dangerous operation!

It doesn't take a whole lot of imagination to figure out two types of task that would completely cripple the system's security and don't even require an additional malware payload to be delivered to the system:

Create a new local administrator user with a password of choice.
Open up the system to remote desktop and remote administration.

(Let's not even get into the fact that you can abuse the task scheduler's log-on scripts feature to bait a domain adminstrator to remote into a prepped system and get their account to register a new domain adminstrator account for yourself...)

FrostCat

Find an example of a system vulnerability on a modern (4.4+) version of Android, executable via an app. It's not gonna be easy to do.

I already did:

"Multiple integer overflows in the GraphicBuffer::unflatten function in platform/frameworks/native/libs/ui/GraphicBuffer.cpp in Android through 5.0 allow attackers to gain privileges or cause a denial of service (memory corruption) via vectors that trigger a large number of (1) file descriptors or (2) integer values."

"Multiple SQL injection vulnerabilities in the queryLastApp method in packages/WAPPushManager/src/com/android/smspush/WapPushManager.java in the WAPPushManager module in Android before 5.0.0 allow remote attackers to execute arbitrary SQL commands, and consequently launch an activity or service, via the (1) wapAppId or (2) contentType field of a PDU for a malformed WAPPush message, aka Bug 17969135."

Magus

Now we wait for him to ignore your post and demand evidence again.

Maciejasjmj

So, if you schedule a task that opens up your computer to being attacked, your computer becomes open to being attacked.

Do I need to forward your post to Raymond Chen's blog? Or do you have an actual attack vector that doesn't involve the user pwning his own system, or the administrator sucking at group policy setting?

Rhywden

I already did:

Yeah, I did as well. He dismissed it because it doesn't give "full root access".

FrostCat

Yeah, I did as well.

I know, and you didn't even have the decency to put a on your post! *sob*.

He dismissed it because it doesn't give "full root access".

, of course.

Ragnax