SQLite C/ADO VBA library with reflection
The SQLiteCAdo library is a VBA middleware facilitating access to SQLite databases. Its two subpackages provide alternative connectivity options: via ADODB/SQLiteODBC and directly via the C-language API. My earlier project, SQLiteDB, is the predecessor of ...
> Hello RubberDuckDev Team, first big big thanks for this great app, very helpful for VBA development ! Recently updated my hardware and want to ask if there will be ARM RubberDuckVBA version? Thank you and keep up the good work.
System: (Processor Apple Silicon, ARM Virtual Machine) Edition: Windows 11 Home Version: 21H2
> Rubberduck is currently compiled with the `Platform` `AnyCPU`, which for probably historical reasons does not seem to include ARM. Since all releases are created through appveyor, this should be fixable by extending the build matrix in .appveyor.yml: https://github.com/rubberduck-vba/Rubberduck/blob/5a0ac77420dc2ef50405bd24007f31903217f67a/appveyor.yml#L28-L32
I'm not certain how that would impact the installer, maybe @bclothier can shed some light on that. As a workaround it should be defi
All I have to do is copy the document to My Documents and it'll open, run the potentially malicious code, and do just as much damage from my local drive as it would from a network drive.
Sure a simple malicious script would only delete the contents of the directory from which it was run and "security" measure means it'd only delete my files. But any skript kiddie worth the name would enumerate all the mapped drives and delete all the files on all of them it could. Heck, I would start with the network drive types, knowing they'd be holding more data...
I suspect it was intended as a measure to limit the damages. One lunkhead unwittingly downloads a malicious script, puts it on the network drive because that's where everyone save their download, tell his coworkers there's a file. They open it and it doesn't work and the world is saved.
so goes the script
<reality>Everyone rush to open the file, get cryptic error, shrugs, copy it to their local drive, open it again and buh-bye, everyone!</reality>
As an added bonus, at my employer, the networked locations are backed up continuously (using versioning), while the local desktop/laptop drives are not backed up at all (unless the user copies to the network).
So it's actually causing more lasting harm by deleting from the local and not the network.
But, by golly, it sure sounds good!
"Lookie what I done, boss man, I prevented a thing!"
2
Boss man pats stooge on the head and gives him a cookie
TBH, I've locked our front screen door with the glass down. However, it was to keep the dog from jumping up, pressing the lever and pushing the door open, not to keep bad actors out.
@this and preventing me from adding a network location to "Trusted Locations" is nothing more that a simple small flip switch behind the screen...
It does nothing but keep the honest folk honest and irritate the snot outta them
Frankly, keeping honest folk honest is all any security measure is good for. The bad guys will simply smash a window and your lock is now pointless.
lol. Actually, having driven past the vault at Fort Knox, it takes a large area with a clear line of sight fire, several rows of barbed-wire fencing, and lots of dudes with heavy weaponry to really keep things safe.
Yeah, tell IT that users can't have Windows for security purposes. :)
Actually, what I really need to do is get off my lazy duff, learn me some C# and just write stand alone applications to do all this stuff. Worst case, I write a small .bat/.cmd file to copy the latest .exe to a local drive and run from there. They can't possibly prevent an .exe from starting a process!
"Hey, boss man, lookie what I done! I done prevented programs from launching threads in Windows!"
Boss man smacks stooge in the back of the head because Windoze no longer loads.
@this Yeah, the very clear lines of fire are a bit of a deterrent and do, somewhat, reduce the curb appeal. However, if you don't like your neighbors...
@FreeMan, the goal is that only administrators should have the ability to write to trusted locations. The average boomer user can only read from these locations. The idea is that we want control of all executable code, not just binaries, but scripts and VBA too. So your admin team would give you, the developer, access to write to the official location where you store your VBA stuff. Then that location can be added as a trusted network location via registry key.
We can also use applocker to make it so the users can't run their code from local paths too. This would stop the copy local and run scenario that you are seeing.
Yeah... well... I have full read/write access to the network (as does everyone else), so, while this may be how you would handle it, it doesn't seem to be hour our IT is handling it.
Also, they make these changes silently and without warning. Things just suddenly stop working.
it's left to the user as an exercise to figure out why.
Presumably, the ability to even download malicious VBA could be blocked at the firewall. This sort of layered approach is known as "defense in depth". Not a single measure will be effective. Various security features need to be combined to have the desired effect.
Communication is important. Are there security meetings you can join to learn about changes and provide feedback?
I'm going to guess you're somewhere in the IT/security/admin world based on some of your responses. That's cool, and it's good to get reasonable feedback and perspective!
I understand the need for security, but it's the poorly thought out way they go about it that's mind boggling.
Our desktop support people used to have LocalAdmin rights on their accounts. They could remotely log into a person's computer (or physically, right there at the keyboard) under their own account to make admin level changes.
Our IT decided that wasn't appropriate anymore and have implemented some sort of system where each machine has its own local admin account with a password that changes every 3 or 4 hours. The desktop guys have to log into a system, look up the local machine name, get the local admin account ID and password to do local admin work on the machine.
That's great, except that laptops that may go for a day or two without connecting to the network via VPN do NOT get their local admin account password updated even though the central system is assigning a new one. There's no way to go back in time to find out what the old password was, so these machines have to come into the office to get resync'd in some way.
It's a bit of a pain to implement but once you get everything configured so that people can do their jobs, there is no reason for a user to ever make admin changes
@HackSlash and this is exactly what most of our IT changes appear to be. There may be some bigger logic to it, but that isn't shared with the rank & file...
Yeah, we use domain accounts that are in the local admin group. The actual local administrator account is never used. It's password can be lost and that would be good. This way we can grant or revoke local admin rights at will.
All actions must be traceable to a real person. So we can't use shared accounts like a local admin.
I understand the need for centralized admin, security, etc. It's just that ours gives the outward appearance of being scattered, harebrained, nonsensical theater that only serves to make everyone's lives more difficult.
Each admin has their own special admin account and local login is disallowed. So you have to log in with your regular account and then escalate privileges with your secret admin account. All of this provides a clear audit trail.
@HackSlash this was auditable/traceable, but isn't any more with this new system. Maybe it changes the password each time someone logs in/out, so it knows who did what by who looked up & used the pwd. I don't know.
@HackSlash IIRC there was a situation where a remote office couldn't talk to the local domain controller and couldn't reach the headquarter's either, so they were effectively all locked out, resulting in a lost workday
that was decades ago and I might not be remembering all the details but it was infuriating because there was the internet and they just need to use documents.
Yeah, you can get crazy with redundancy. Two routers on two ISP accounts with two VPN tunnels, etc. Or three, or four. It gets difficult to configure active-active load balancing and you need special hardware like an F5. It's not cheap
Well, just connect a Boston Dynamics robot to StarLink. Then boot up google android assistant connected to the google quantum computer for backend processing. Give it some ML\AI freewill and let er rip.
and the headlong millennial rush to accept these things without thinking through the possible consequences is more than a little scary! (I've had many discussions with my 22 yo son about these things.)
@this If he calls it a vaccine, he can't be sued. Job done.
Oh, the other "fun fact" about this stupid security theater, is that all I have to do is click the "enable macros" button that the Office app helpfully supplies. So if I believe that code should run, I'll do that, only to discover later that someone modified it to be malicious.
So that's an important step to allow users to back out of a shady file. It requires user training to be of any use. It's unlikely that your controlled copy could be changed. If it was changed then you already have a different infection or compromise that allowed that to occur.
Frankly, I had to work hard to train my users to click that (until I could get their machines set up with trusted locations). They'd click it out of habit/lack of knowledge. They're medical people, not IT people - they don't think about things like this, it's not their job and it shouldn't be.
Besides, we've been told that our network locations are HIPAA compliant for security, so we can store PII & PHI there. In theory, anybody hacking in would be stealing PHI data, not corrupting VBA code.
@FreeMan Who said the line "Your scientists were so occupied with whether they could they didn't stop to consider whether they should" in Jurassic Park? Alex, obscure references for $800
In defense of MS, they do make many (but not all) scheduling configurations fairly easy. Recurrence: The 1st weekday of every 3 months is a handy reminder for quarterly reporting (especially since we have to wait a full month after quarter end for financials to be done before we can start our quarterly reporting).
Unfortunately, The 10th weekday of every 3 months isn't an option.
Right, so let's keep our eyes on the ball here. The goal of blocking VBA is to stop a malicious VBA macro from loading malware that can exfiltrate your HIPAA protected data. You say your network location is compliant but that's not relevant. If your user account has access to the data and your user account is running the malicious VBA code then the attacker now has access to your "compliant" data.
So blocking VBA is part of their compliance effort.
VBA is a legitimate attack vector, in fact, it's quite common today.
So how can you allow your home grown software to run, while stopping users from running code in a random office file they get from the web or email?
(I described one strategy involving trusted locations and file permissions)
The other strategy would be signed code. That's harder to do because it involves a trusted code signing certificate.
@HackSlash The fact that they set it up to prefer a schema where you pay someone a gob of money to tell the whole world that yes, you're you is kind of where it went all wrong, IMO.
Because the typical scenario is VBA code authored to address a specific internal requirement that is of little interest outside of the world, self-signing a certificate at the IT dept should be sufficient. No need to fork over gobs of money.
This doesn't address the VBA code that is shared and used within a setting since that's external and needs to be independently vetted.
Still doesn't change the fact that SSL ecosystem is one giant racket that doesn't actually do what it's supposed to do.
For inexplicable reasons, MS has decided to disallow VBA code signing in Access but is A-OK with it in Excel. Makes zero sense but who am I to expect otherwise from MS.
@this I fully agree. It's exceedingly complicated and sometimes unworkable because nobody is doing it. You can spin up an internal CA whose certificates are trusted by pushing that trust down through the domain. It's a lot of infrastructure to avoid paying the SSL tax yearly. So it's going to be expensive either way. The same is true for any software. As you point out, it's much worse in the VBA world, as many things are. That is why Microsoft made these new macro blocking rules.
The M$ stance appears to be that we need to be migrating away from VBA in secure environments but they haven't given us a good migration path.
They also haven't provided a good mechanism for trusting VBA applications, like Access. I've signed Excel macros and it sucks.
If we could get an updated VBE with a simple mechanism for trusting code it would be trivial to open each project and trust it. Maybe it could be tied to an AzureAD identity so that you could easily assign security group permissions to trust VBA code. As an AzureAD identity protected by MFA is a strong trusted identity already.
Make a "developer" security group, throw your users in there and they have the magic power to allow their code to work.
(Just one of many features that we need in an updated VBE to continue the legacy)
They have the trust mechanism with the big yellow bar but I don't know how to restrict who can push that button.
It needs to be tied to the code and not the file. Or the file has to become untrusted each time the code changes, requiring the developer to approve the new code change.
@HackSlash The problem is that even though they have this "security" since Office 2003, there are users are basically trained to just blow through the dialogs and there are other users trained to never ever download anything from the interweb because they can't trust that it wasn't maliciously injected. it accomplishes nothing except annoying everyone. I think you have the right idea --- the permission to author code or scripts should be handled at the OS level.
It doesn't really matter what languages or scripting engines we're talking about; anything that can compile or execute arbitrary source code ought to require a OS level permission then it's a matter of tying the author's identity to the users' computer so we know that only that author and not this author can make changes for those users.
As part of a software whitelisting project you would only allow approved applications to run. If you're going to allow a command interpreter to run then you need a way to sign the code.
So really, the problem is code signing certificates.
VBA Rubberducking
VBA Rubberducking