Wire: Expression 2 server crash exploit/bug

[ghost]

Hello, here is Expression 2 server crash exploit/bug.
Use this code and attach it to any prop:
@name Problem Solver
if(first()){
runOnTick(1)
}
entity():isWeldedTo():setPos(vec(0,0,0/-1))

then server will instant crash.

[bigdogmat]

entity:setPos(number, number, number) isn't a function in any of the default extensions, or any of the included custom extensions.

Contact the creator of the E2 extension you're using

[ghost]

Woops, i messed up on the code, now it is correct.

[Divran]

This https://github.com/wiremod/wire/blob/master/lua/entities/gmod_wire_expression2/core/e2lib.lua#L31 is supposed to prevent exactly this. Either the clamp function isn't catching this use case, or your server isn't using wire's included version of prop core.

[bigdogmat]

0/-1 would return -0, which wouldn't be clamped, I'm not quite sure the cause of the crash here

[ghost]

@Divran I haven't modified or added any external extensions

[Divran]

Does it still crash if you remove runontick?

[bigdogmat]

Does running it with 0 instead of 0/-1 crash as well?

EDIT: Also what are you putting the E2 on? i.e. what is isWeldedTo returning?

[ghost]

@bigdogmat It can be any prop, just choose whatever you wish to.

[bigdogmat]

I just tested your exact code in single player and on a dedicated server, neither crashed.

Is your wiremod up to date?

[ghost]

@bigdogmat It seems that github version of wiremod doesn't crash on this code, it was workshop version in use when this crash came. The others i posted on issues should still work.

[bigdogmat]

@47d3467 fixed the issue then

[Divran]

That shouldn't have fixed it since this e2 doesn't use setpos more than once per tick

[bigdogmat]

That shouldn't have fixed it since this e2 doesn't use setpos more than once per tick

It's true, removing that commit didn't make it crash for me. Possibly he has an extension that executes E2s? I can't think of any other reason it'd not crash this update

[CaptainPRICE]

@bigdogmat

47d3467 fixed the issue then

Nope.

@Divran And it didn't. Tried it yesterday, it crashed on master branch.

[bigdogmat]

@CaptainPRICE What did you test in? Also what OS?

[CaptainPRICE]

Literally, crashed on Windows and Linux server (OS has nothing to do with this, it is independent):

interval(1)
entity():applyForce(vec(1e54))

Unfreeze E2 after spawned, and it will crash, because it is not clamped.. See here.

[bigdogmat]

Literally, crashed on Windows and Linux server (OS has nothing to do with this, it is independent)

I asked because Linux has known to be a bit unstable when it comes to vphysics.

Also that code you posted has nothing to do with what OP posted, wrong issue?

[CaptainPRICE]

Oh snap. I thought I was posting in applyForce issue.
Okay, I have tested this, and it doesn't crash on master branch, so it was fixed.

#ifdef entity:setPos(vector)
interval(1)
entity():setPos(vec(0 / -1))
#endif

#ifdef entity:setPos(vector)
interval(1)
entity():isWeldedTo():setPos(vec(0 / -1))
#endif

#ifdef entity:setPos(vector)
interval(1)
entity():setPos(vec(-1 / 0))
#endif

#ifdef entity:setPos(vector)
interval(1)
entity():isWeldedTo():setPos(vec(-1 / 0))
#endif

None crashed (on Windows).

[TomyLobo]

@CaptainPRICE Cannot reproduce != Fixed

[CaptainPRICE]

Cannot reproduce != Fixed

k. But, if it doesn't crash on Windows, then it is "_fixed_". That's what I meant.
As I haven't tested above on Linux, I couldn't reproduce it, so it is "_not fixed_".

[TomyLobo]

If your test case works now and you don't know whether it worked before, you don't know if the bug is fixed or if the test case is just inadequate.

[bigdogmat]

If the test code crashed every single time on an older version and now doesn't, one can only assume it was fixed. Considering what was changed, we can assume 2 things. 1, something was causing his E2 to update on spawn and so setPos was called twice in one tick. 2, It's completely unrelated somehow.

[chinoto]

Isn't this a server-side issue? If so, then it breaking on Linux does matter because we've had the capability to have Linux GMod servers long before the Linux client came out, so I would presume that a decent percentage of dedicated GMod servers could be on Linux, especially when we're talking about the more "professional" servers.

Regardless of that, to me, if a bug can be reproduced at all on the latest revision, it is worth worrying about, unless there are higher priority bugs to deal with. I wish I had a working capable computer to help out with debugging and possibly fixing :cry:

[bigdogmat]

Isn't this a server-side issue? If so, then it breaking on Linux does matter because we've had the capability to have Linux GMod servers long before the Linux client came out,

Since when did breaking it on Linux come into question?

especially when we're talking about the more "professional" servers.

Though this isn't as true as it used to be, however there is still truth to it, Gmod (source in general) runs better on windows, always has.

Regardless of that, to me, if a bug can be reproduced at all on the latest revision,

(speaking for the people that did test it, that is @CaptainPRICE and myself) No one here could reproduce it on any version. As for op, they've said they can't on the latest version.

[chinoto]

I probably went through the thread too quickly, sorry about being a nuisance :disappointed:
It does make sense that Source would work better on Windows when that's where the market share had been locked to for a long time..

[oldmud0]

GMod sandbox servers are generally held to low standards since anyone can do anything, including spamming entities and crashing the server. DarkRP, TTT etc. are held to some standard, but I haven't seen many DarkRP servers with Wiremod fully enabled (since most people only use Wiremod because they're trying to paste a dupe that requires it).

[Divran]

GMod sandbox servers are generally held to low standards since anyone can do anything, including spamming entities and crashing the server.

False. This is only a general fact that applies to any server host who have no clue what the hell they are doing, including TTT/DarkRP (actually, I'd wager that DarkRP has more barely-out-of-diaper-babies playing admin than sandbox does).

[oldmud0]

all right so if I have a clue, am I supposed to look through the code and patch security holes in all of my 125 mods or what?

[Divran]

No, you install known mods made by experienced developers, and not the first weapon pack riddled with backdoors you can find on the workshop. And then you report security holes on the mod's issue page.

EDIT: sorry for late reply lel

[Nebual]

None of the scripts in this thread crash my Windows or my Linux server, closing as unreproducable (feel free to reopen if you can still cause it with an updated git copy of Wire)

[ghost]

@Nebual This was fixed long ago, not sure why it was still open.