Security issue

[Edgar]

I just created a user that has Standard privs and UAC enabled. I am able to reproduce Dale's bug.
This means I need to figure out a fix and will let JimS upload the fix later.

[Edgar]

The fix might actually require a User folder sooner than later. It seems Vista prevents a program from writing a file in the Program Files folder with only a Standard type of User Account.

[Dale]

Originally posted by Edgar:

Dale,
Do you have UAC enabled?
I am curious if it is failing to write a file in the MA26 folder.  

To answer the question - yes, UAC is enabled, and this is an account with administrator privs. But no UAC prompts appear (which is what I would expect if the program is trying to write a file there)

[Dale]

Originally posted by Edgar:

The fix might actually require a User folder sooner than later. It seems Vista prevents a program from writing a file in the Program Files folder with only a Standard type of User Account.  

Yes. In fact, I believe that the expected behavior would be (regardless of whether it's a standard or administrator account) for UAC to pop up a dialog box requesting permission to write the file. Depending upon the type of account, as well as the actual operation, there might be either one or two dialog boxes, and (if it's a standard account), an administrator's username and password would be required.

(That's required for making any changes in "system folders" like \Program Files\)

In any case, the account I was using was an administrator account - not a "standard" user account.

And I didn't see any UAC prompts or dialog boxes, other than the one I quoted.

[Dale]

Originally posted by Edgar:

I am curious if it is failing to write a file in the MA26 folder.  

That looks to me as if the approach is "security through obscurity".

In other words, "if the user doesn't know that security involves writing a file, then the user won't be able to get around the security..."

**OPINION (if I'm seeing that correctly)** Please find another way. Security through obscurity isn't security. Corporate security folks would not allow this to be called secure.

If I'm misreading the tea leaves, please ignore this post.

[Jim Sachs]

I didn't undestand that last post at all.

[Shinsa]

A physical example of "Security through Obscurity" would be putting up dry wall over a hole in bank vault wall. Nobody knows its there, and can't see it, unless they are looking for it.

Jim, sorry about continuing the thread on the Vista login bug. I last downloaded on Monday, which was 8b I believe. I didn't check for more updates, thought that would be next week. My bad.

[Dale]

Analogy: some people put their emergency cash in an old beer can in the refrigerator. No burglar would ever think of looking there.

Or, if I hide the front door key in that real-looking fake rock in the flowerbed...

If software "security" is based on "nobody would ever think of doing that to get to do something bad", it's not very secure. Somebody is sure to think of doing it.

Recent analogy: Just because the "website" button lets someone get to a web browser (without putting in a password), nobody would think of how to abuse that.

The whole area is generally called "security through obscurity". In other words, if you hide the exposure well enough, it's "not a problem".

In this case, I (perhaps incorrectly) inferred that the "security" solution depends on writing (and/or running) a file, which is hidden from the user.

Let's say it depends on running a script - and if the script isn't there, then it writes the script file, and then runs it.

User finds the file, MODIFIES the script, and then PROTECTS the file from being replaced. Now, when the "website" button causes the script to be executed, it is the MODIFIED script. Does whatever the user wanted.

That's all speculative, of course. But if the "security" depends on writing or reading a user-modifiable file (i.e., a file in user space), it's just not technically "secure". It's just "obscure".

Did that explanation help to understand my (possibly totally off-base) comment?

[rps]

I understood it. What Dale is saying is, that if Edgar's approach to solving the security to hole is to "hide" it, by writing a file somewhere that the [typical] user isn't likely to find, that isn't really an acceptable solution.

Here's the thing: if "require a password" is enabled for a screen saver, then Windows creates a dedicated session for the screen saver to run in. This session has some default userID (call it the "null user" if you will), and the screen saver, plus any applications launched by the screen saver, will run in this session. In XP, when the screen saver terminates, the null user's session terminates immediately, killing any other processes that might still be running. (Such as the internet browser that is now trying to go to the Serene Screen website.) In Vista, the null user's session continues to run until ALL processes in the session have ended. If UAC is enabled, then the null user will only have access to those things that Everyone can access. In either case, the password to return to "unlock the computer" does appear until *after* the null session terminates. Everything that I've described so far is what Windows imposes, and which you have no choice about.

Now, how to deal with this? Here's the problem, you have to keep in mind that if you're in the null session, you aren't really supposed to have access to the rest of the computer. (You might, if UAC is disabled, but you can't count on that.) Which means that even if you get to the website, you won't be able to download an update. And there's no way to close the screen saver and launch the browser *after* the user has logged back in, because that would require an application in one user session (the null session) launching an application in another user session (the original user). Can you imagine the potential for viruses if that were actually possible?

Which brings me back to: if the owner of the computer specified that the screen saver should run in a secured (null) session, then really, the screen saver is the *only* thing that should run in that session. (Ever.) And therefore, launching a browser to go to the Serene Screen website shouldn't be allowed. (Unless it was a custom browser that *only* allowed you to visit the Serene Screen site, and *nothing* else, but I think we dismissed that already...) From a security standpoint, I still think the right answer (and the easiest to implement) is to see if: (a) the program was launched in screen saver mode, and (b) if so, is it running in a null session. If both (a) and (b) are true, then disable (or hide) the website button. Remember that users can access the website button by viewing the list of screensavers and accessing the properties dialog for the MA3 screen saver. Or by clicking on the desktop icon to launch the program manually (in non-screensaver mode). [The install program *will* offer to put an icon on the desktop, right?]

Bear in mind that most dedicated screen savers terminate as soon as any key is pressed or the mouse is moved. The fact that MA3 allows you to access the properties dialog from an active screen saver, makes it somewhat unconventional.

~Ralph S.

[Edgar]

Dale, Let's just say your inference is wrong. There is no obscurity going on.
I do appreciate the help you are giving.

[feldon34]

Originally posted by Edgar:

It seems Vista prevents a program from writing a file in the Program Files folder with only a Standard type of User Account.  

That is one of the principal security features of Vista -- Thou Shalt Not Write to Program Files.

This is why programs which have a truly automatic update feature (they actually rewrite their own data files) must be set to Run As Administrator in Vista and Win7. This is considered a cop out though, and programs written to work for Vista/Win7 are supposed to be able to run without Run As Administrator checked.

An overall design element of Vista is that you cannot truly login as Administrator. Instead, you login as the standard user and must elevate your privileges any time you want to do a task that is deemed by Vista or Windows 7 as an Administrator-only task.

Data is supposed to be stored in Documents and Settings under the appropriate user or under All Users. I guess for the time being you could do All Users and figure out user support later.


I find Vista UAC to be tedious at best and from what I have read of Win7's UAC, they missed the point people were making. Apple has UAC spot-on. Applications downloaded from the Internet get prompted. Installing software gets prompted. That's really about it. Tasks you perform every day such as launching older applications or moving folders to the desktop do not get prompted on Mac. They do on Vista.

[rps]

By the way: on XP, using beta8f, and screen saver set to require password: I still can't access the website. (Whatever process is being launched when I click the button, dies as soon as MA3 closes.)

~Ralph S.

[Dale]

Originally posted by Edgar:

Dale, Let's just say your inference is wrong. There is no obscurity going on.
I do appreciate the help you are giving.  

OK. Sorry for the digression.

[Jim Sachs]

As we've talked about before, the MA3 Beta uses the MA2.6 folder and Key Code, so that you guys can try it out using your old 2.6 Keys. Once we switch to the real MA3 Key Codes and folder, everyone will need a new Key.

[Dale]

Originally posted by rps:

By the way: on XP, using beta8f, and screen saver set to require password: I still can't access the website. (Whatever process is being launched when I click the button, dies as soon as MA3 closes.)

~Ralph S.  

I confirm that.

In other words, on XP with the proper conditions, the "website" button is broken. MA3 exits through the "account/password" screen, as it should, but -- no browser page.

Perhaps because there is no .js file to be found in C:\Program Files\SereneScreen\Marine Aquarium 2.6

[Jim Sachs]

Try 8g: http://www.fish-byte.com/MA3Beta.zip

[Dale]

Originally posted by Edgar:

Dale, Let's just say your inference is wrong. There is no obscurity going on.
I do appreciate the help you are giving.  

I finally had time to "hack" the situation and get the openserenescreen.js file created.

For the info of folks watching this thread - essentially all that script does is "http://www.serenescreen.com" (with the appropriate amount of fiddling to get the environment right).

This is clearly done in "user" context, after a correct password has been supplied.

Edgar - I didn't doubt your word - I was just curious.

But I will note that "where to put the .js file" is not necessarily a simple question.

[Dale]

Originally posted by Jim Sachs:

Try 8g: http://www.fish-byte.com/MA3Beta.zip  

Seems to work on Vista Ultimate 32-bit.

Still doesn't work on XP (security is OK, but doesn't get to website).

[Shinsa]

MA3 v.8g security seems fine on Vista 64 SP1 Home Premium now.

[Jim Sachs]

Yeah, but it's broken on XP. Edgar has a fix, which I'll post as soon as he's done with a different bug.