- Dec 29, 2014
- 1,716
I believe VB in Office is supposedly there for the sake of automation of MS Office/office tasks (as mentioned by @Andy Ful). Within Office, the language supports finding and grabbing data in row/column of a spreadsheet or database A, etc. to move the data to word B or to another Excel file or even mail it in Outlook or whatever. It can also fetch data in an MSO file or in some other standard database across the intra/internet, for example, when a file is opened, etc. I guess the problem is introduced as a result of the fact that VB can be also used to update files and tabs from outside of Office on a timed schedule, etc. and then that it can be used to manipulate non-Office files on a system (create/delete, etc.) Worst of all it can apparently be used to create an executable file outside of MSO. This should not be possible imo. As far as I know all of the functions of MSO are activatable and usable via VB macro in Office...almost an infinite combination of possibilites here. Then too I am 90% sure that Java or other languages can also be added to MSOs macro interface for use (just for knowledge sake if someone knows). VB is really powerful in Office though. Don't think companies would ever need another language for getting the most from MSO if it could be trimmed to a safe MSO only language.
As mentioned, one question I have is whether VB can be used from within MSO to create files of a format other than supported by MSO. I assume this is easily possible, since file drops can happen from an actual infected file. Seems to me this would be a good place to start limiting the capabilities of VB. Why shouldn't MS think of it as a macro language for use exclusively from within documents for operations on MSO documents?
Actually, I am fairly impressed that MS could easily clean up VB and limit its usability inside and outside of Office. The language seems to me to just simply be too powerful. MS could have a great leg up on everyone if VB were safe to use.
I also have had a similar question about VBS, which is why is it even useful or usable outside of Office. There are a dozen languages other than VB that someone could use for interacting with MSO data or automating tasks, etc. How many languages do there have to be? LOL, maybe the test for creating a safe new language for macros in MSO should be to ask of each capability whether in its current form it would run in a script host...if yes, then change or remove the capability. This would require companies to take the time to write apps in order to automate beyond simple macro in and across file automation. VB could be limited then to automation during standard use of MSOffice files...from one MSO document to another or from MSO document to a common database format or whatever...never creation of a file of a format other than MSO or known database (definitely not any sort of executable)...
I'm more or less a noob with VB, but I have seen how powerful it can be just within a single Office file. Excel can basically be turned into a program creation tool (even with only MSO data references), honestly, and it's very useful in this way. IMO, it's worth saving for that reason. That said, I could see why someone would just say punt MSO and go back to old school application building making use of old fashioned databases. Don't think this would be any safer though, considering VB should be improvable (in my best estimation anyway) to the point that it could be considered safe to use macros for working with MSO documents...
As mentioned, one question I have is whether VB can be used from within MSO to create files of a format other than supported by MSO. I assume this is easily possible, since file drops can happen from an actual infected file. Seems to me this would be a good place to start limiting the capabilities of VB. Why shouldn't MS think of it as a macro language for use exclusively from within documents for operations on MSO documents?
Actually, I am fairly impressed that MS could easily clean up VB and limit its usability inside and outside of Office. The language seems to me to just simply be too powerful. MS could have a great leg up on everyone if VB were safe to use.
I also have had a similar question about VBS, which is why is it even useful or usable outside of Office. There are a dozen languages other than VB that someone could use for interacting with MSO data or automating tasks, etc. How many languages do there have to be? LOL, maybe the test for creating a safe new language for macros in MSO should be to ask of each capability whether in its current form it would run in a script host...if yes, then change or remove the capability. This would require companies to take the time to write apps in order to automate beyond simple macro in and across file automation. VB could be limited then to automation during standard use of MSOffice files...from one MSO document to another or from MSO document to a common database format or whatever...never creation of a file of a format other than MSO or known database (definitely not any sort of executable)...
I'm more or less a noob with VB, but I have seen how powerful it can be just within a single Office file. Excel can basically be turned into a program creation tool (even with only MSO data references), honestly, and it's very useful in this way. IMO, it's worth saving for that reason. That said, I could see why someone would just say punt MSO and go back to old school application building making use of old fashioned databases. Don't think this would be any safer though, considering VB should be improvable (in my best estimation anyway) to the point that it could be considered safe to use macros for working with MSO documents...
Last edited: