All Activity

@BIGNEWY As you are soliciting feedback, here's mine. Please forward this to your developers. I've reported an arbitrary code execution vulnerability, initially in December '24, which I presume may be related to this API change. Recently, I've also suggested a straightforward mitigation method that would incur far less collateral damage than the current approach. TL;DR The new net.dostring_in() security option is ill-suited: It only mitigates the vulnerability in a basic configuration, its configuration can be easily changed from privileged scripts (rendering it useless), and, most importantly, it cannot be configured to allow required, legitimate use of net.dostring_in(), while simultaneously preventing potential exploits. The changes cause a lot of collateral damage, while not fixing the root cause of the vulnerability. IMHO, this change should be reverted and ultimately substituted with a superior alternative. This alternative should be co-developed with community contributors that rely on the scripting API to find a proper solution. Inofficial Security Advisory What this fails to mention is that DCS versions from at least 2.9.10 (probably sooner) thru 2.9.17 are vulnerable to arbitrary code execution via specially crafted mission files. I'll responsibly refrain from divulging any further information. Suffice it to say that I figured out how to exploit the vulnerability from information that I gleaned from this forum, so the required knowledge is already out there. The exploit does not require the now added return value pass-thru of net.dostring_in(), which is apparently broken anyway. Beware of untrusted mission files in combination with exemplary autoexec.cfg files out there! As predicted by many previous posters, I've already seen a few autoexec.cfg incarnations with potentially unsafe settings. Anything that includes "scripting" in net.allow_unsafe_api is presumably dangerous. Kudos to ED for clearly pointing this out in %DCS_INSTALL_DIR%/API/Sim_ControlAPI.html: net.allow_unsafe_api = { "userhooks", -- will make the API visible in _$WRITE_DIR/Scripts/Hooks/*.lua_ scripts "scripting", -- enables the API in the mission scripting state. DANGEROUS!!! "gui", -- system hooks and GUI state } @BIGNEWY This very important detail is hidden away. I'd suggest to add it to your first post in this thread. Technical Background To comprehensively address the efficacy of the security option, I first have to outline my understanding of the technical background of net.dostring_in(). @Experts: Please correct me if I'm wrong with anything! DCS relies on multiple Lua interpreter instances to isolate different scripting zones/environments/namespaces from each other. They contain entirely separate global environments (_G variable). These are called lua_State in the Lua documentation and are also referred to as states in DCS' documentation. The states are isolated from each other, but some applications require to run code and get return values from other states. That is where net.dostring_in() comes in: AFAIK, the following Lua states exist: "config", "export", "gui", "mission", "server", "scripting" (new since DCS 2.9.18; separate from a_do_script()), and "userhooks" (new since DCS 2.9.18). Some of these states are trusted and privileged, e.g., "gui", "server", and "userhooks". These are allowed to read and write arbitrary files and call external programs, which is how SRS launches the client automatically on SRS-enabled servers. Other, unprivileged states run untrusted code from mission files, e.g., the "mission" state. Potentially dangerous Lua functions, e.g., for writing files and calling executables, are sanitized from these unprivileged states. @BIGNEWY What's the purpose of the new "scripting" state? It appears to be a separate Lua state from both "mission" and a_do_script(). Benefit / Efficacy The implemented security option restricts the use of net.dostring_in() within privileged, trusted Lua states, too. As these states already have access to privileged Lua functions, using net.dostring_in() to access a different state will not result in privilege escalation. Also, if the respective state can write files, it can modify autoexec.cfg and edit net.allow_* to change the security options to more permissible ones (after a game restart). Hence, attempting to restrict these privileged states is entirely useless. Unfortunately, that design choice has an unpleasant side effect: To permit the already privileged states to access all other states, implies permitting the non-privileged states to access all other states, too, because there's only one global net.allow_dostring_in setting shared between all source states (where net.dostring_in() is called from). A real-world example would be the need to let "userhooks" access "server" (e.g., Olympus) and let the mission scripting state ("scripting"?) access the "mission" (triggers) state, e.g., to access functions like a_unit_set_life_percentage(). That would result in the exploitable situation, where mission scripting can access the "server" state. The breaking changes do not fix the root cause of the vulnerability, which is the availability of potentially dangerous functions that allow unrestricted read/write file access and the execution of arbitrary programs. Cost / Breakage Scripting in DCS is already not trivial due to the fragmented Lua states, requiring workarounds that rely on net.dostring_in("mission", ...) [1, 2] and a general lack of documentation. Incompatible API changes that break these workarounds frustrate the mission makers that desperately rely on them. The alleged obsolescence of net.dostring_in() (see above quote) adds to the feeling that the developers are not fully aware of what their API users actually need. There are many uses for net.dostring_in(), e.g., Olympus, Lua consoles, etc., for which a_do_script() is not an alternative. I'd highly recommend to discuss such drastic API changes with the community well in advance. Alternative The suboptimal design choice for the security option unnecessarily restricts privileged states, can be easily bypassed by those states, and is ill-suited for standard use cases, e.g., Olympus + access to "mission" state from a_do_script(). It is not worth the collateral damage in terms of API incompatibility, which breaks community content. The new security option should be removed and the behavior of the scripting system should be restored to DCS 2.9.17. To alternatively mitigate the arbitrary code execution vulnerability, while simultaneous permitting legitimate use of net.dostring_in() from mission scripting, the following wrapper function could be placed within %DCS_INSTALL_DIR%/Scripts/MissionScripting.lua: ---BEGIN-MISSION-SCRIPTING-EXPLOIT-MITIGATION--- -- insert this block into %DCS_INSTALL%/Scripts/MissionScripting.lua above: -- --Sanitize Mission Scripting environment -- mitigate arbitrary code execution vulnerability with a wrapper for -- `net.dostring_in()` that restricts its access to the "mission" Lua state. -- accessing the "mission" Lua state is required for some advanced scripting: -- * https://forum.dcs.world/topic/354648-add-setlife-function-to-lua-api/ -- * https://forum.dcs.world/topic/358877-lua-function-unitsetlife/ -- * https://forum.dcs.world/topic/371036-outpicturefor-lua-mission-scripting-functions/#findComment-5672179 -- this copies `net.dostring_in()` into a lexically scoped local variable and -- then overwrites the original function with a wrapper, which captures the, -- local exclusively, because Lua is scoped lexically: -- https://www.lua.org/pil/6.1.html local _dostring_in = net.dostring_in function net.dostring_in(lua_state, code) if lua_state == "mission" then local _result, _success = _dostring_in("mission", code) return _result, _success else -- TODO: add error logging return "Invalid state name", false end end ---END-MISSION-SCRIPTING-EXPLOIT-MITIGATION--- Obviously, this is provided as is, without any warranty of any kind (as per the stipulations of the MIT license). You should know your code better than me to figure out whether this is safe or not. Regardless, I hope this helps make DCS safer, while keeping mission makers happy.

And that's an honest worry, Hell, the Hawk 'guarantee' was what gave me trust in handing ED $80 per virtual plane But here we are with the F-15 nuked, 1 year in public, 5 years after people have been told this problem was dealt with So,..which modules are still under the old stipulations? Seems everything announced and under development ATM which isn't ED's can be relegated to abandonware when things go sideways

Good evening, Since the last update, I experience almost constantly CTDs of DCS upon touchdown on the carrier. This happens both in the Tomcat and in the Hornet. Does anyone else have, or had, the same issue? Best regards.

What kind of recourse did Steam users actually have? As far as I know, no refunds, no store credit, and no alternatives were offered ... unlike ED store customers. Were there any real options available that I might’ve missed?

100% agree, I'm in that boat myself. It's no mystery that RB has been a bad faith actor and anyone who doesn't seem to get that is really trying their hardest. But, the idea that ED will shrug at us if nothing happens and just pull those 3 modules from the software when we hit 3.0? That's unacceptable. Pure and simple. The fact that ED wouldn't stop and see that as such? Talk about rudderless.

Do you perhaps have a track? In my very limited testing, they only appear, if you are slow, at 1.6Gs, or fast at 2Gs and above. So if you see them in level flight with a hint of back pressure, either it's more than just a hint of back pressure, or you are slow to begin with.

The updated manual is in the install folder of the AH-64D module. For example: G:\Eagle Dynamics\DCS World\Mods\aircraft\AH-64D\Doc\

I'm gonna push your butt against the stove for this one: So, which 3rd party modules would be lost to updates if their developer decides to not work with you anymore? It's ok you don't have that info, someone at ED does and can tell you.

Appreciate that and that’s really all I’m trying to get across. I’m not taking sides here... I just believe both parties should be held accountable. This isn’t about choosing ED or Razbam, it’s about the fact that paying customers are stuck in the middle with no real clarity. The situation doesn’t need miracles just transparency and responsibility. And let's not forget about those who have the other three modules.

yeah, but I still recall those users having some recourse.

I think that goes without saying and that was the case even before this issue. Though, don't operate under the assumption that if ED upsets everyone, we'd see a huge exodus to the other. The result will be a reduction in player numbers for a time before people forget and go back to whatever it was they preferred. That'll make a whole lot of gamers butthurt to hear, but it's the truth. I'd just want more flight sims, truthfully.

We just tested it. Every person has to call inbound. It can’t just be a flight lead, everyone in his group must call in individually to prevent CTD

Agreed I'm upset with both sides

What DCS and the community need is commercial competition. DCS is basically the only product in the realistic combat flight sim market.

If you can't get things settled then all I ask of ED is please make your own Strike Eagle, Harrier, MiG-19, and Mirage 2K

I at least agree with this sentiment. Pushing for a little more clarity cannot hurt.

Unless he has on Steam, he won't get anything for a known reason.

this has been reported to the team. thank you

Yes, Razbam deserves equal criticism... their communication and conduct have been extremely unprofessional. But the key difference here is that ED still holds the keys to the platform, and they’re the ones continuing to sell products and build community trust. So naturally, the responsibility to maintain that trust also falls on them... not just Razbam. At the very least, ED should be honest about their limitations and stop leaning on vague statements like "we hope for a resolution." People deserve clarity, not deflection.

The solutions and FIX are here and work fine: https://www.lotatc.com/news/2025/07/23/Last-DCS-fix.html

Да я тоже локти кусаю, что Харриер не купил в свое время. Ну да что теперь. Я ориентировался на эту фразу: "Eagle Dynamics confirms that it signed a settlement agreement with Razbam at the end of 2024 to put an end to the existing disputes and that such agreement also provides for a strict confidentiality requirement that prevents Eagle Dynamics from disclosing further information". Источник: https://forum.dcs.world/topic/372249-edrazbam-situation-info-discussion/

The approach light is not a standard landing light. It's an approach light used by Paddles for carrier landings at night. It's activated by lowering the tail hook. https://thanlont.blogspot.com/2012/04/night-carrier-landings-in-beginning.html

Is the Val a 3rd party mod?

I have been around DCS since the very beginning, playing the first A-10 game at release. Somewhere down the line years after, vortices were introduced or maybe just broken. In level flight, with just a hint of back pressure, I get heavy swirling vortices. In the A-10, I have to push the stick forward to get rid of them. Almost every input (minus nose down) creates these effects. It's to the point of ruining the game for me (not being able to enjoy the breathtaking exterior visuals). How can I get rid of these things? Any mods? Settings? I would SERIOUSLY even pay someone to find a way. How has this not been fixed yet? Surely I can't be the only one who thinks they need some work? I would absolutely love to return. Fingers crossed.