A safety net

[tperry2x]

Not entirely convinced.

Please go back and re-read this previous post.
Try opening the stack in this post, turning ON "Suppress messages", so messages are supposedly "Suppressed", then open the stack "script run tests.oxtstack"

2025-01-18-17-48-04.png (21.11 KiB) Viewed 1366 times

Besides which, you'll find IDE scripts don't get run properly with suppress messages turned on either.

Or even better, turn on "Suppress messages" and open this stack. (I promise it does nothing nasty )

suppress-test.oxtstack

(783 Bytes) Downloaded 8 times

But that's the point, you shouldn't have to trust (or take the gamble) that there's nothing nasty in stacks.

If you want to see how it works, hold shift key while you open the stack. This will prevent the quit message from triggering, and then look at the script of group 1 on the first card.
Perhaps LC just forgot about the preOpenControl and OpenControl handlers?? - But this remains a way to run script with the "Suppress messages" turned on, as you can see.

[richmond62]

https://forums.livecode.com/viewtopic.p ... 59#p233059

Code: Select all

...
lock messages
go stack "path/to/stack.livecode"
...

[tperry2x]

Nice try, and thanks for your input Klaus, but...
lots of messages are also fired when closing the stack. It does not suppress these after being opened, so again - these are all areas where malicious scripts could be run from:

close-but-not.png (221.83 KiB) Viewed 1346 times

[tperry2x]

However, perhaps a combination of both techniques.
Lock the messages before opening the stack, open the stack, then immediately set the suppress messages to true... that might be worth a go...

Yes, that combination of both techniques works. I adapted (made a copy & modified) the "Suppress Messages" function a bit to suit my needs. (It will display a confirmation window and explanation of what it's done and why it's done it).

works.png (45.28 KiB) Viewed 1339 times

The snag with that though, is that it leaves the IDE in a bit of a precarious / disabled state with the messages suppressed. It clears the frontscripts, the backscripts and the pendingmessages - and this also means that lots of things start to just not function across the IDE until messages are resumed (Unsuppressed) - better than needing a restart of the IDE, as this can all be resumed by:

Code: Select all

revIDEToggle "Suppress Messages" -- run it again to turn everything back on

which does:

Code: Select all

revInternal__UnloadLibrary "revNoMessagesLibrary"
put false into gREVSuppressMessages

(then restores the frontscripts and backscripts as to how they were when the IDE loaded).

[tperry2x]

So the short version is:

Approach A:
Build in numerous mechanisms to lock the messages, load the stack, toggle the suppress messages to ON, display a dialog explaining how these changes stop parts of the IDE working, explain that some features may not be available (even middle-clicking to change the cursor is disabled because the frontscripts are unloaded), the message box stops working fully, most of the menuitems stop working, the preferences window doesn't save changes, the tools palette breaks when it's sections are adjusted, the message watcher is borked (obviously - no messages), the lessons stack won't load, the About stack won't load, neither will the updater, internal messages stop getting sent and received by the revIDELibrary, and the dictionary won't load.... there's probably more.

So, not being funny, but nope!

Approach B:
Read the binary data of the stack without opening it, and show a window with the entire script in.

Approach B has my vote.

[richmond62]

One thing that is worth reflecting on, is that if xTalk stacks are potentially so dangerous, why:

1. Does it not seem to have been spotted (& acted on) in the last 20 years?

2. Have people 'over there' been merrily opening everyone's stacks for years without "a condom"?

[tperry2x]

Haha, probably a bit of both.

1. Does it not seem to have been spotted (& acted on) in the last 20 years?

The engine is a product of it's time. For example, any modern IDE which is capable of making changes to files on disk (outside the project files you are directly editing), will always prompt you with an "Are you sure you want to allow this" type warning.

The LCC / OXT IDE is different from most as it can be modified inside of itself to do/be whatever you want. In that respect it's a bit unique. Although this is brilliant for us, and gives us the flexibility to tweak it how we want - it does that regardless of what change you want to make. (malicious changes included).

2. Have people 'over there' been merrily opening everyone's stacks for years without "a condom"?

Yes, although Klaus does elude to it here that he takes some precautions, they are not nearly enough to stop any malicious script getting through alone. He mentions he's been using that method for 20+ years - I think the "security through obscurity" comes to mind. The fact that it's all so niche, isn't seen as a target for something that can be readily exploited easily - that's probably the reason it's not been done.

Doesn't mean we should stick our heads in the sand and ignore it. In fact, quite the opposite.

Now, you are going to think I'm on my mac-bashing trip again here - but hear me out.
On Windows and Linux, if you want to make a change to the files in the IDE, you have to edit things with elevated permissions. This puts up the box asking for permissions (UAC prompt on Windows, Authentication on Linux).
On MacOS though, because you can install (drag) the application to any folder (one that might be writable, like your desktop or home folder), you have permissions to edit these ".livecodescript" files easily. (it inherits the permissions from the parent folder, meaning they are writable).
Given then that ANY program can edit the .livecodescript file (such as "home.livecodescript") as they are just text files, ANYTHING could be tacked onto that file and saved on MacOS without the user's knowledge. (I've just done this with an innocuous looking applescript on MacOS 14 as a proof of concept). I can add whatever destructive shell command or IDE function (recursively destroying stacks in the IDE if I want) without so much as a popup appearing.

So, I think it's better that the IDE on MacOS be placed in /Applications (Sorry: /System/Applications - as mentioned with Apple's hidden directory mask changes) - but having these directories 'world-writable' which are executable by the IDE is just asking for problems in the modern age of people looking to exploit things.

Perhaps I'm worrying, but if the OXT IDE ever gains wider use, it can easily become a vehicle for malware delivery really simply. What's the old saying.. "it takes 10 years to get a good reputation, 10 minutes to get a bad one". Once it gets thought of as a PUP (Potentially unwanted program), then that's the end of the engine and IDE as we know it.

As I say, preventing these files being user writable without explicitly asking for permissions would be a step towards that on MacOS, as they are in Linux and Windows - if you don't install to a location that is writable by any process of course.

[richmond62]

OK: Loud and clear.

BUT: how are you going to

1. enforce Mac users to bung OXT in /system/applications?

2. get an app that is NOT made by Tim Cook and his merry men to be allowed in that folder?

[tperry2x]

1. enforce Mac users to bung OXT in /system/applications?

That's relatively easy, by writing an Applescript which prompts the user to install it in /Applications and asks for user permission to do so.

2. get an app that is NOT made by Tim Cook and his merry men to be allowed in that folder?

Being an Applescript, conversely - it's automatically on the 'trusted' list by Apple, no matter what the code inside actually does. (I know, crazy)

[FourthWorld]

This is a deep topic. Even if you don't use the securityPermissions, reviewing the options reminds us of the scope of defensive design.

For example, we might not consider the implications of something like taking screen shots, but if you think about it...

[tperry2x]

There's also something else to bear in mind.
Windows defender uses reputation based detection, - and this is built into windows 10 and 11.
As soon as LCC or OXT gets flagged as being a malicious program with Microsoft, any users on Windows where the automatic smartscreen updates ("Security Intelligence updates" as they call them) - have taken hold, will find that they will be unable to open the IDE / the engine. Also of note, because this uses the app signature to determine if standalones have also been created with LCC/OXT - there's potential for these to be blocked too. Meaning that you won't be able to launch your standalones and LCC/OXT IDE. - until Microsoft are notified and remove it from the "security intelligence update" list of known suspect programs. They did this with AnyDesk and then eventually allowed it after a lot of protest from many companies and individuals.

Same is true for MacOS with Apple adding certain application names to the sandbox protection service (sorry, daemon on MacOS - equivalent to a "Service") - they did this with "Clean My Mac" and "MacKeeper" (before it supposedly changed hands) - they remotely blocked these apps from running for a while (think it was back around 10.9 or 10.10 if memory served). Any mac that tried to run them, which had an internet connection - was prevented from running them. This wasn't done via codesigning - just to be clear, this was reputation based app protection using Apple CDHashes. (Through XProtect. It looks up a set of known malware in what it calls "Yara rules") - No, I'm not making this up - even though it sounds like it.

[richmond62]

no matter what the code inside actually does

Well, if that is the case I'll use AppleScript for my 'next' thing to hose someone's computer instead of OXT.

Considering how much Apple rants on and on anent security, signing, stamping, tattooing, registering, and so on, I find that very hard to believe indeed.

Unless, of course, Apple's rant about security is nothing of the sort, just an attempt to squeeze out developers of software who are not prepared to pony up loads of moolah to Apple for the ever so slightly dubious privilege of running their stuff on Mac.

[tperry2x]

It's perfectly possible. You can try it and give it a go easily enough.
Create an applescript on your mac - save as an applescript application.
Inside that applescript, create something potentially nasty. I don't know, the world is your oyster - you can have it delete all the files in ~/Documents if you like.
Save the script and copy it to another mac. It'll run unchallenged because it's a signed application.
The same is true for any program that creates other programs that can enact shell scripts (or any file modifying behaviour) - such as Platypus on the Mac for example. The difference here though is that newer versions of MacOS will block the app's ability to make changes as it'll prompt the user. Not so for Applescript.

(speaking of which, in the documentation of Platypus, they mention the difficulty of getting Apps to open other apps automatically and how this is now blocked by security APIs on newer macOS):

stderr output cannot be captured due to limitations in the Security APIs. This can be circumvented by using a shell script to execute another script while piping stderr into stdout (e.g. python script.py 2>&1).

I mention this, as it's the method I'm effectively using on MacOS to achieve the respring after an update, but this circumvention only works up to a point.

Anyway, yes - Apple's insistence on ensuring only things that come from the app store could be rightly seen as a money spinner for them (27% of the cost of your app, or 12% respectively for apps distrubuted through the app store). This is why you can find some apps are free when going direct to the developer's homepage, yet charge a fee when the same app is distributed through the app store.

There's lots of app developers who initially didn't want to use the Mac App store, but those developers have either gone now or been forced into using it by the OS. (or just continue to provide links on their sites, until Apple won't allow these apps to be run one day, or limit what they can do).

But I'm getting off topic.
I'm merely pointing out just a few of the ways that this can all be messed with, if you had a mindset to do so.
However, the misuse of either LCC/OXT and/or standalones created with it (because they all share the same underlying code base) can have knock-on effects for everyone once they get listed as being 'malicious'. - They'll all be tarred with the same brush.

[richmond62]

Inside that applescript, create something potentially nasty.

Sorry: not even tempted.

At the moment I'd rather get on with some Anglo-Saxon.

https://openxtalk.org/forum/viewtopic.php?t=1328

[OpenXTalkPaul]

You wouldn't need to have root permissions on linux, and at least MacOS - as this is only deleting each file recursively from your home directory - where you already have user permissions for those files, as you are the owner of the files in your home directory (broadly speaking).

It's running as a loop, so anything that it encounters that it can't delete - it moves onto the next one it can. It's very destructive, and I certainly wouldn't want to run that - but I can run this destructively on a sacrificial user account on Linux - and Also on MacOS 14 at least - where it actually freaks out and prevents that user account from being logged into anymore(!)

Ah, I must have missed the tilde there!

Normally when you run an app on newer macOS it needs the appropriate keys set, and approval to allow that sort of filesystem access, but a stack is not an app and my version of the IDE's info.plist has keys to request all sorts of access to hardware (Filesyste, Camera, Microphone). Once approved by the user for the IDE Engine then any stack file would be pre-approved to use it as well. That definitely amounts to potential for malicious scripts. That's another nice thing about script-only stacks, you can read them with any text editor before opening them with the IDE.

[OpenXTalkPaul]

Can extract the scripts of every object in a stack without normal opening of a binary stack? That way the scripts could be reviewed before loading the stack normally?

[OpenXTalkPaul]

1. enforce Mac users to bung OXT in /system/applications?

That's relatively easy, by writing an Applescript which prompts the user to install it in /Applications and asks for user permission to do so.

/system/applications/ is not the same as /applications/
You can't (normally) write to /system/applications/ only Apple can, right? I'm not 100% since this is fairly recent change in macOS.

[OpenXTalkPaul]

Save the script and copy it to another mac. It'll run unchallenged because it's a signed application.
The same is true for any program that creates other programs that can enact shell scripts (or any file modifying behaviour) - such as Platypus on the Mac for example. The difference here though is that newer versions of MacOS will block the app's ability to make changes as it'll prompt the user. Not so for Applescript.

Are you sure? I mean I thought AppleScript applets were ad-hoc signed for the user that saved it as an app, so it shouldn't work if you move it to another mac unless you signed it using a certificate that is also installed on the other mac's keychain. If not i would think that would trigger 'Gatekeeper' or it would at least ask the user permission to run. I could be wrong though.

I mention this, as it's the method I'm effectively using on MacOS to achieve the respring after an update, but this circumvention only works up to a point.

Have you looked into Sparkle?
https://sparkle-project.org/
There was also a WinSparkle. Trevor DeVore packaged them into a xBuilder wrapper for using with his Levure frakework. The source is on his github:
https://github.com/trevordevore/lc-sparkle
https://github.com/trevordevore/lc-winsparkle
I would've thought that Sparkle would hit up against the same sort of problems with newer security measures, but I don't know. It looks like the Sparkle project is still actively being developed. Although it looks like Trevor hasn't updated his Sparkle wrappers in about 7 years, it might not need any updating since it's a wrapper around the library binaries.

The mac engine previously (v6/7) used an Applescript (it's still in the repo). The AppleScript being inside the IDE app's bundle was probably enough for it to run with the security as it was back then (>10 years ago). I know with POSIX compliant systems a process launched by another process should inherit the parent processes permissions,

[OpenXTalkPaul]

Windows defender uses reputation based detection, - and this is built into windows 10 and 11.
As soon as LCC or OXT gets flagged as being a malicious program with Microsoft

My OXT for win binary might not be seen as the same binary as LC Community because it's been modified with a Resource Editor (embedded icon an other metadata was changed).

With any development tool, you could create and run malicious code. Which is allegedly the reason Apple wants people to use XCode (and not VSCode or similar), plus code-signing with dev's certificate, submited for review, notarized, stapled (not kidding), and in triplicate

[tperry2x]

...That definitely amounts to potential for malicious scripts. That's another nice thing about script-only stacks, you can read them with any text editor before opening them with the IDE.

However, with script-only stacks, ANY text editor can also write to them . And insert what someone wants, to later be run with OXT/LCC without the user necessarily being aware.