Invisible wrote:
> (That's what Office 97 had.)

Actually, Office 97 had a way for a macro to turn on the "don't disallow 
macros" flag. A true security cluster-fk. Like, huh? Disallow macros, 
unless the macro with the malware in it says to allow macros?

> (By default they install VBA but not the tools apparently necessary to 
> actually enable it to run. 

No. The tools to let it run, but not the tools to make new macros. Just 
like having by default a Java VM runtime installed without installing 
the Java compiler.

> I wonder - how do you develop new code if it's always disabled until you 
> sign it?

The same way you develop new code if it's always unrunnable until you 
compile it.

> (And - one hopes - every time you change it this invalidates 
> the signature...)

Yes. That's the point of it.

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

And MS could have made it easier by identifying the minimum subset of 
macro functions that are necessary for virus propagation, and 
eliminating enough of those functions to make virus propagation impossible.

Simply never writing macros to normal.dot would have stopped the 
propagation of many viruses, and depriving macros of the ability to 
disable menu commands would have helped, too.

Regards,
John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> Simply never writing macros to normal.dot would have stopped the 
> propagation of many viruses, and depriving macros of the ability to 
> disable menu commands would have helped, too.

  It's not the first time when MS's concept of fixing a security hole is
to either ignore it (by argumenting it's not a problem) or going completely
overboard, instead of actually fixing the problem itself.

  Somehow it gives the impression of a beginner and proud-of-itself
programmer who is given a bug report. He either is too proud to admit
the problem, or can't imagine a better solution to it than to disable
half of the functionality of the program. You know, like those cases you
can constantly read at the daily WTF.

-- 
                                                          - Warp

Post a reply to this message

I basically agree with everything you two have said.

How about you ask the user before letting a macro perform a potentially 
risky action? (Unless it's signed of course.)

OTOH, some idiots will click anything put in front of them, so... how 
about just turn off all potentially unsafe functionallity unless the 
macro is signed, and say "hey, get the macro author to sign this if you 
really want it to work"? (But provide no way to actually enable the 
macro just by clicking the window.)

The vast majority of macros are for auto-generating document content. If 
you turn off the ability to access other files / documents and disable 
changing the user's settings, it's pretty much impossible for a 
malicious macro to do anything except screw up the document it's already 
infected. Dude, how hard is that?

But hey, why do that when you can just completely disable all macro 
functionallity?

(Question: Has anybody ever actually *seen* a macro virus? I'm told they 
exist, but I've never ever come across one...)

Post a reply to this message

And lo on Fri, 07 Dec 2007 09:58:06 -0000, Invisible <voi### [at] devnull> did  
spake, saying:

> I basically agree with everything you two have said.
>
> How about you ask the user before letting a macro perform a potentially  
> risky action? (Unless it's signed of course.)

I believe that's called Vista ;-)

> OTOH, some idiots will click anything put in front of them, so... how  
> about just turn off all potentially unsafe functionallity unless the  
> macro is signed, and say "hey, get the macro author to sign this if you  
> really want it to work"? (But provide no way to actually enable the  
> macro just by clicking the window.)

Then you'd just get the 'unsafe' macros being signed, unless you want to  
force everyone to buy a certificate?

> The vast majority of macros are for auto-generating document content. If  
> you turn off the ability to access other files / documents and disable  
> changing the user's settings, it's pretty much impossible for a  
> malicious macro to do anything except screw up the document it's already  
> infected. Dude, how hard is that?

Except where you want a macro to be able to access other documents and  
files and change settings. For example IIRC in one version of Word to  
print out a document to a non-default printer via VBA requires you to  
change the default printer to the one you want to print to then change it  
back again.

> But hey, why do that when you can just completely disable all macro  
> functionallity?

Because it's easier

> (Question: Has anybody ever actually *seen* a macro virus? I'm told they  
> exist, but I've never ever come across one...)

In the early days when they were new, sure. Not so much nowadays.

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

Warp wrote:
> John VanSickle <evi### [at] hotmailcom> wrote:
>> Simply never writing macros to normal.dot would have stopped the 
>> propagation of many viruses, and depriving macros of the ability to 
>> disable menu commands would have helped, too.
> 
>   It's not the first time when MS's concept of fixing a security hole is
> to either ignore it (by argumenting it's not a problem) or going completely
> overboard, instead of actually fixing the problem itself.

Aside from the recurring buffer overruns bugs (it seems like one of 
those pop up every month[1]), every security hole appears to involve a 
feature that MS added for its own benefit, and not for the user's.

IE is a good example of this.  Frankly, everything that isn't directly 
related to displaying content formatted in HTML should be relegated to 
plug-ins that the user can shut off at will.  That includes automatic 
download, install, JavaCurse^H^H^H^H^HScript, and so on.

>   Somehow it gives the impression of a beginner and proud-of-itself
> programmer who is given a bug report. He either is too proud to admit
> the problem, or can't imagine a better solution to it than to disable
> half of the functionality of the program. You know, like those cases you
> can constantly read at the daily WTF.

Disabling half of the functionality in IE would be a pretty good idea.

Regards,
John

Post a reply to this message

John VanSickle wrote:

> Disabling half of the functionality in IE would be a pretty good idea.

Or perhaps... you know... providing a way to uninstall IE? ;-)

-- 
http://blog.orphi.me.uk/

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Or perhaps... you know... providing a way to uninstall IE? ;-)

  There is: Uninstall Windows.

-- 
                                                          - Warp

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> wrote in message
news:475f19d0$1@news.povray.org...
> John VanSickle wrote:
>
> > Disabling half of the functionality in IE would be a pretty good idea.
>
> Or perhaps... you know... providing a way to uninstall IE? ;-)

Add/remove programs -> Add/Remove Windows Components. Uncheck Internet
Explorer.
(At least on my windows 2000 box)

Post a reply to this message

Gail Shaw escribió:
> "Orchid XP v7" <voi### [at] devnull> wrote in message
> news:475f19d0$1@news.povray.org...
>> John VanSickle wrote:
>>
>>> Disabling half of the functionality in IE would be a pretty good idea.
>> Or perhaps... you know... providing a way to uninstall IE? ;-)
> 
> Add/remove programs -> Add/Remove Windows Components. Uncheck Internet
> Explorer.

Did you read the description of that "component" carefully? The only 
thing that will remove is the SHORTCUT.

Post a reply to this message