| Time |
Nick |
Message |
| 00:16 |
|
Taoki joined #minetest-dev |
| 00:38 |
|
AliasAlreadyTake joined #minetest-dev |
| 01:04 |
|
v-rob joined #minetest-dev |
| 01:21 |
|
erlehmann joined #minetest-dev |
| 01:28 |
|
v-rob joined #minetest-dev |
| 01:33 |
|
erle joined #minetest-dev |
| 01:34 |
|
erlehmann joined #minetest-dev |
| 01:36 |
|
HuguesRoss joined #minetest-dev |
| 02:45 |
|
Menchers_ joined #minetest-dev |
| 03:28 |
|
queria^clone joined #minetest-dev |
| 03:33 |
|
queria^clone joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:52 |
|
v-rob joined #minetest-dev |
| 07:20 |
|
tekakutli joined #minetest-dev |
| 08:26 |
|
calcul0n joined #minetest-dev |
| 09:00 |
|
Fixer joined #minetest-dev |
| 09:11 |
|
Fixer_ joined #minetest-dev |
| 10:19 |
|
erlehmann joined #minetest-dev |
| 10:26 |
|
Fixer joined #minetest-dev |
| 10:30 |
|
appguru joined #minetest-dev |
| 10:30 |
|
nemo42 joined #minetest-dev |
| 10:34 |
|
HuguesRoss joined #minetest-dev |
| 10:54 |
erlehmann |
rubenwardy are you interested in getting a CVE assigned for minetest 5.3.0 item stack meta injection so distributions update? https://security-tracker.debian.org/tracker/TEMP-1004223-7F4004 |
| 10:55 |
sfan5 |
sane distros have already updated |
| 10:56 |
erlehmann |
sfan5 debian and all its derivatives have 5.3.0 in stable |
| 10:56 |
erlehmann |
afaik |
| 10:57 |
erlehmann |
https://repology.org/project/minetest/versions |
| 10:58 |
erlehmann |
sorry world is insane place |
| 11:08 |
|
JordanL2 joined #minetest-dev |
| 11:09 |
MTDiscord |
<Sublayer plank> debian is for people who like outdated packages anyways :P |
| 11:11 |
erlehmann |
as a contributor to gnu unifont, i can tell you that debian has a really fast turnaround time if you interact with them |
| 11:12 |
erlehmann |
whereas ubuntu will ship your stuff in a shitty state for like half a year |
| 11:18 |
|
proller joined #minetest-dev |
| 11:26 |
|
nemo42 joined #minetest-dev |
| 12:00 |
|
srifqi joined #minetest-dev |
| 12:08 |
MTDiscord |
<Benrob0329> yeah that sounds about right |
| 12:09 |
|
srifqi1 joined #minetest-dev |
| 12:16 |
|
srifqi2 joined #minetest-dev |
| 13:20 |
|
dzho joined #minetest-dev |
| 13:29 |
erlehmann |
https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories |
| 13:29 |
erlehmann |
> Anyone with admin permissions to a repository can create a security advisory. |
| 13:38 |
rubenwardy |
We should add a `server_contact` setting which is sent to the serverlist, so we can send warnings to server owners before making these things public |
| 13:40 |
rubenwardy |
> It might be possible to backdoor the server by injecting Lua. |
| 13:40 |
rubenwardy |
this is false |
| 13:40 |
rubenwardy |
it would require a mod to loadstring on item meta, which is crazy and they definitely shouldn't be doing |
| 13:41 |
rubenwardy |
mods can do anything with code, this vulnerability should be categorised based on what we know they do not what they could do |
| 13:42 |
rubenwardy |
what is more likely is that they store content which they deserialize, in which case would allow a denial of service |
| 13:56 |
erlehmann |
rubenwardy what i have seen so far: acquiring any node (even illegally stacked) and items with modified meta |
| 13:57 |
erlehmann |
superweapons for example |
| 13:58 |
erlehmann |
rubenwardy how were you made aware of this problem by the way? |
| 13:59 |
erlehmann |
or did you find it yourself |
| 13:59 |
rubenwardy |
disclosure |
| 13:59 |
rubenwardy |
we have a policy on how to report a vuln and how we do a patch, we don't have a policy on making the vuln public |
| 13:59 |
rubenwardy |
that may be desirable |
| 14:00 |
erlehmann |
well, if i understand the ppl from the debian games team correctly, issuing a CVE will motivate ppl to upgrade minetest |
| 14:00 |
rubenwardy |
I'd suggest once we make a fix, we first contact server owners using `server_contact`, wait a week, then make public |
| 14:00 |
erlehmann |
or at least take that patch |
| 14:00 |
erlehmann |
also, any scenario i can come up with right now that allows you to corrupt server code without crashing it is super convoluted, too. but i rather err on the side of caution. |
| 14:02 |
erlehmann |
rubenwardy did the person who disclosed it give you some proof of concept maybe? like “write this in a book and see the magic happen”? |
| 14:08 |
|
queria joined #minetest-dev |
| 14:17 |
erlehmann |
rubenwardy so far, the “worst” real-world thing that i can think of right now is the mcl maps mod. it stores the filename of the map in the meta. i guess that means access to files that the maps mod can read! ^^ |
| 14:17 |
erlehmann |
but as i said, it is convoluted |
| 14:20 |
sfan5 |
>we first contact server owners using `server_contact`, wait a week, then make public |
| 14:20 |
sfan5 |
that doesn't really achieve anything unless you also hide the fix from the public |
| 14:21 |
erlehmann |
i agree |
| 14:22 |
erlehmann |
people will find immediately that you can name an item “\x02return { default:dirt 69 }\x03” or something like that |
| 14:22 |
erlehmann |
i probably forgot some quotes here |
| 14:28 |
rubenwardy |
what conditions does GitHub have for issuing CVEs? |
| 14:37 |
erlehmann |
i have no idea |
| 14:45 |
erlehmann |
rubenwardy btw, do you think my minetest-servers tool does belong into minetest proper? i find it incredibly useful |
| 14:46 |
rubenwardy |
not heard of that |
| 14:47 |
erlehmann |
it just parses the metadata and outputs values for some kay in “server $VALUE” lines |
| 14:47 |
erlehmann |
for example, to know where the party is, i do: ; minetest-servers clients |sort -k2 -n |tail -n3 |
| 14:47 |
erlehmann |
edgy1.net:3002530 |
| 14:47 |
erlehmann |
147.189.172.35:3002335 |
| 14:47 |
erlehmann |
jt2.intraversal.net:3000243 |
| 14:49 |
erlehmann |
or, to get a list of public servers that have a specific mod, i can do: minetest-servers mods |grep tga_encoder |
| 14:49 |
rubenwardy |
seems like a nice third party tool, I don't see any reason to make it official |
| 14:50 |
erlehmann |
oh okay |
| 14:50 |
erlehmann |
well basically i do stuff that the gui does not let me do, like find players |
| 14:50 |
erlehmann |
; minetest-servers clients_list |grep -i kitten |
| 14:50 |
erlehmann |
skyblock.telesight.nl:30011cute_kitten |
| 14:51 |
erlehmann |
but i guess if that is not supposed to be part of minetest proper, where does it belong? |
| 14:51 |
erlehmann |
is there some tool collection? |
| 14:51 |
rubenwardy |
https://forum.minetest.net/viewforum.php?f=14 |
| 14:51 |
erlehmann |
thx |
| 15:00 |
|
nemo42 joined #minetest-dev |
| 15:12 |
|
Fixer joined #minetest-dev |
| 15:36 |
|
tekakutli joined #minetest-dev |
| 15:42 |
|
v-rob joined #minetest-dev |
| 16:15 |
|
v-rob joined #minetest-dev |
| 17:00 |
|
Fleckenstein joined #minetest-dev |
| 17:06 |
|
v-rob joined #minetest-dev |
| 17:35 |
sfan5 |
https://github.com/minetest/minetest/security/advisories/GHSA-7q63-4fq2-hqcr doesn't seem like a real vulnerability |
| 17:35 |
sfan5 |
or at least not "High" |
| 17:38 |
erlehmann |
sfan5 i can't see it and can't edit it |
| 17:41 |
rubenwardy |
that is determined by the CVSS score |
| 17:42 |
rubenwardy |
I can add erlehmann to all the draft advisories that's desired |
| 17:43 |
erlehmann |
desired by whom? ^^ |
| 17:43 |
rubenwardy |
our lizard overlords |
| 17:46 |
rubenwardy |
arguably, because that bug requires a mod to have a security issue then maybe "network" isn't a valid attack vector |
| 17:47 |
erlehmann |
hey, i have seen that behaviour |
| 17:47 |
erlehmann |
it's totally normal to find reasons why something does not apply |
| 17:47 |
erlehmann |
but please do not |
| 17:48 |
erlehmann |
if this thing ever becomes more than “creative mode on every 5.3 server” it will be over the network |
| 17:51 |
rubenwardy |
sfan5: if you click edit, you'll see there's a CVSS calculator |
| 17:52 |
rubenwardy |
CVSS doesn't seem capable of handling finese |
| 17:52 |
rubenwardy |
The TL;DR is that this fix reduces the impact of a vulnerable mod from RCE to denial of service |
| 17:53 |
rubenwardy |
erlehmann: you should be able to see it now |
| 17:53 |
erlehmann |
thx |
| 17:56 |
erlehmann |
rubenwardy i think the text should also contain that even without vulnerable mods there is the issue of players having access to nodes and items they should not have by editing the meta. |
| 17:56 |
rubenwardy |
this isn't about editing meta |
| 17:57 |
erlehmann |
ah |
| 17:57 |
rubenwardy |
I mention this issue in the itemstack meta one, as the itemstack meta one can then abuse this hole |
| 17:57 |
erlehmann |
now i see! |
| 17:58 |
rubenwardy |
yeah, this should be high |
| 18:01 |
erlehmann |
rubenwardy uh … the carts in minetest game for example i guess? |
| 18:01 |
erlehmann |
nah that's only the entity |
| 18:05 |
erlehmann |
rubenwardy, local mode=minetest.deserialize(item["metadata"] like this? |
| 18:05 |
erlehmann |
bc that's in the portal gun thing |
| 18:05 |
rubenwardy |
sure, but valid code |
| 18:06 |
rubenwardy |
item["metadata"] isn't part of the Minetest API, so preassuming that they're making a table with metadata stored there then yes |
| 18:06 |
erlehmann |
492-function portalgun_mode(itemstack, user, pointed_thing)-- change modes |
| 18:06 |
erlehmann |
493-local item=itemstack:to_table() |
| 18:06 |
erlehmann |
494:local meta=minetest.deserialize(item["metadata"]) |
| 18:06 |
rubenwardy |
ah |
| 18:06 |
rubenwardy |
not sure if the meta injection can be done on the metadata field, it might just be meta |
| 18:07 |
rubenwardy |
ok yes it can |
| 18:07 |
rubenwardy |
it's key="" |
| 18:31 |
MTDiscord |
<savilli> what's it about, someone deserializes data from clients again? |
| 18:40 |
MTDiscord |
<luatic> erlehmann: theoretically, minetest.deserialize should be safe from RCE due to sandboxing the executed Lua though? |
| 18:45 |
rubenwardy |
it wasn't sandboxed pre 5.2 |
| 18:48 |
MTDiscord |
<luatic> oof |
| 19:09 |
sfan5 |
minetest.deserialize is never safe |
| 19:09 |
sfan5 |
you can literally pass "while true do end" to it |
| 19:09 |
rubenwardy |
see #minetest-staff |
| 19:09 |
erlehmann |
TL;DR: computers were a mistake |
| 19:20 |
sfan5 |
the whole issue is that "we made passing untrusted data to a function not meant to handle untrusted data a bit more safe" is not really a security fix |
| 19:20 |
sfan5 |
neither is "passing untrusted data to a function not meant to handle untrusted data is bad news" a security bug |
| 19:21 |
rubenwardy |
it's a chain vulnerability, when combined with another vulnerability |
| 19:21 |
erlehmann |
well, you usually have to chain stuff to get to anywhere |
| 19:21 |
|
v-rob joined #minetest-dev |
| 19:21 |
rubenwardy |
We could ditch that vulnerability and make https://github.com/minetest/minetest/security/advisories/GHSA-hwj2-xf72-r4cf high |
| 19:22 |
erlehmann |
rubenwardy, wdym ditch? |
| 19:22 |
rubenwardy |
close https://github.com/minetest/minetest/security/advisories/GHSA-7q63-4fq2-hqcr |
| 19:22 |
rubenwardy |
and instead include the RCE part of it in the meta injection advisory |
| 19:23 |
sfan5 |
I'm pretty sure the rating of the first one you linked is wrong |
| 19:23 |
sfan5 |
if you flip "integrity" to high then it bcomes high too |
| 19:23 |
rubenwardy |
first one being item meta? |
| 19:23 |
sfan5 |
yes |
| 19:23 |
sfan5 |
"A mod workaround isn't possible" <- this is not true btw |
| 19:24 |
erlehmann |
rubenwardy “Some mods create items from item meta, which would allow malicious users to get unlimited free items.” this is actually limited by the length of the injectable meta. this means that some items can still be unobtainable. |
| 19:24 |
rubenwardy |
I suppose you could sanitise it at every point |
| 19:25 |
sfan5 |
erlehmann: to my knowledge MTG contains no such mechanism, but that's not relevant anyway as we're writing an advisory for the engine |
| 19:25 |
erlehmann |
in fact, i did unintentionally confused a friend of mine by having an illegal item that had a name longer than what said friend was able to achieve. i did, of course, acquire it in an entirely legitimate salvaging operation (i.e. by mysterious other means than meta injection). |
| 19:26 |
erlehmann |
sfan5, yeah but there are a bunch of anvil mods |
| 19:27 |
erlehmann |
well, then again … books exist, so it prob does not matter. sorry! |
| 19:27 |
sfan5 |
books don't get you free items |
| 19:27 |
rubenwardy |
other games exist |
| 19:31 |
MTDiscord |
<luatic> sfan5: I'm aware, but that's DoS vs. full-blown RCE |
| 19:32 |
rubenwardy |
sfan5: added a workaround |
| 19:32 |
erlehmann |
i think free items are the least of anyone's worries on real servers. even without *any* engine bugs, literally everyone implementing a non-trivial crafting node makes some bookkeeping errors. |
| 19:33 |
rubenwardy |
<sfan5> if you flip "integrity" to high then it bcomes high too |
| 19:33 |
rubenwardy |
Without RCE, it allows changing items and possibly giving items. You can't delete all data |
| 19:33 |
erlehmann |
but DoS and RCE are |
| 19:36 |
erlehmann |
I have indeed seen items with illegal meta on 5.4, and wondered for a long time how they got created – until I got told they were created in 5.3. |
| 19:38 |
erlehmann |
rubenwardy, “by removing control characters being setting ItemStack meta:“ should be “by removing control characters being set in ItemStack meta:” |
| 19:38 |
rubenwardy |
actually s/being/before/ |
| 19:38 |
erlehmann |
oh, or that |
| 19:42 |
erlehmann |
rubenwardy maybe add that item meta based “Denial of Service attacks.” can include both server and client. if throw a player a handful of items with overlong meta, they may experience lag during play or login. see https://2b2t.miraheze.org/wiki/Bookbanning |
| 19:46 |
rubenwardy |
not sure there's a meaningful difference there |
| 19:47 |
erlehmann |
the difference is that a) admin might not notice b) anon5 developed a proxy to counter this problem |
| 19:47 |
erlehmann |
in fact, some servers were running this proxy to sidestep the issue |
| 19:48 |
erlehmann |
not sure if any do now |
| 19:48 |
erlehmann |
https://github.com/OysterityAnarchy/mt-netopt-proxy might be it |
| 19:49 |
|
proller joined #minetest-dev |
| 19:55 |
rubenwardy |
would interact be None or Low on "privileges required" |
| 19:55 |
rubenwardy |
probably None |
| 19:55 |
rubenwardy |
as we default to granting it, and it's usually trivial to get |
| 19:55 |
|
v_rob joined #minetest-dev |
| 19:55 |
rubenwardy |
at which point, this is critical |
| 19:56 |
rubenwardy |
if you merge in deserialize into this report |
| 19:56 |
|
v_rob joined #minetest-dev |
| 19:57 |
rubenwardy |
I still think that deserialize should be a separate report. It's a chain vulnerability that would be better split off |
| 19:57 |
erlehmann |
then have two and reference one from the other? |
| 19:57 |
rubenwardy |
that was my plan, sfan5 disagrees |
| 19:59 |
MTDiscord |
<luatic> deserialize is a separate report IMO |
| 20:11 |
|
nemo42 joined #minetest-dev |
| 20:27 |
erlehmann |
what would be the best way to sidestep the camera in player head issue? can having a player model be disabled? https://github.com/minetest/minetest/issues/11987 |
| 20:27 |
MTDiscord |
<luatic> erlehmann: what about backface culling? |
| 20:28 |
erlehmann |
luatic do you think backface culling is the *cause* of this? because i do not think so |
| 20:28 |
erlehmann |
like missing backface culling |
| 20:29 |
MTDiscord |
<luatic> enabling backface culling might be a less problematic workaround than disabling the player model altogether |
| 21:33 |
sfan5 |
the best way is obviously to fix the driver |
| 21:34 |
sfan5 |
or switch to ogles2 which might not have this issue |
| 21:41 |
|
YuGiOhJCJ joined #minetest-dev |
| 21:52 |
sfan5 |
had a brilliant idea today #11988 |
| 21:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/11988 -- Add game name to server status string by sfan5 |
| 21:53 |
|
Yad joined #minetest-dev |
| 22:19 |
|
proller joined #minetest-dev |
| 22:29 |
|
YuGiOhJCJ joined #minetest-dev |
| 22:31 |
|
asdflkj_sh joined #minetest-dev |
| 22:44 |
|
v-rob joined #minetest-dev |
| 23:06 |
erlehmann |
there seem to be specific angles in which you can look outside of the map and the skybox vanishes |
| 23:06 |
erlehmann |
anyone has had that? |
| 23:06 |
erlehmann |
look outside of the map = standing at the edge of the map looking outwards |
| 23:10 |
|
Toothless joined #minetest-dev |
| 23:10 |
MTDiscord |
<Jonathon> if the sky is just a small part of the screen it can just go to grey |
| 23:11 |
MTDiscord |
<Jonathon> altho i always assumed that was the indoors part of set_sky being broken |
| 23:16 |
erlehmann |
Jonathon, it happens when the sky is a large part of the screen |
| 23:16 |
erlehmann |
it just goes black (or dark gray?) |
| 23:16 |
MTDiscord |
<luatic> yeah, it's a feature I believe xD |
| 23:16 |
erlehmann |
sfan5 i do not understand this change and the commit message does not seem to help https://github.com/minetest/irrlicht/commit/7d1dc8b2d54ada305e4e2caa38debf35a171c52d |
| 23:17 |
erlehmann |
since you made it, can you explain? |
| 23:20 |
erlehmann |
i have read this https://docs.microsoft.com/en-us/windows/win32/dxtecharts/game-timing-and-multicore-processors |
| 23:20 |
erlehmann |
> Compute all timing on a single thread. Computation of timing on multiple threads — for example, with each thread associated with a specific processor — greatly reduces performance of multi-core systems. |
| 23:21 |
erlehmann |
is this relevant to the code you removed? |
| 23:22 |
erlehmann |
> Set that single thread to remain on a single processor by using the Windows API SetThreadAffinityMask. Typically, this is the main game thread. While QueryPerformanceCounter and QueryPerformanceFrequency typically adjust for multiple processors, bugs in the BIOS or drivers may result in these routines returning different values as the thread moves from one processor to another. So, it's best to keep the thread on a single |
| 23:22 |
erlehmann |
processor. |
| 23:24 |
erlehmann |
sfan5 maybe you have a newer article, but to me it seems what the code did before was what is listed in the article. |
| 23:25 |
|
YuGiOhJCJ joined #minetest-dev |
| 23:31 |
erlehmann |
maybe someone can point me to the issue the removal of the thread affinity multicore code is supposed to solve. i was not able to find one. |
| 23:39 |
|
Sokomine joined #minetest-dev |
| 23:47 |
erlehmann |
i made an issue. i should have done that in the first place. sorry: https://github.com/minetest/irrlicht/issues/94 |
