| Time |
Nick |
Message |
| 00:00 |
|
TheCoffeMaker joined #luanti-dev |
| 00:04 |
|
TheCoffeMaker joined #luanti-dev |
| 01:37 |
|
MTDiscord joined #luanti-dev |
| 02:14 |
|
cranez joined #luanti-dev |
| 02:16 |
|
cranez left #luanti-dev |
| 02:16 |
|
mtdeveloper joined #luanti-dev |
| 02:36 |
|
mtdeveloper left #luanti-dev |
| 03:05 |
|
cranez joined #luanti-dev |
| 04:03 |
|
SFENCE_arch joined #luanti-dev |
| 04:12 |
|
SFENCE joined #luanti-dev |
| 04:18 |
SFENCE |
From crash log and lldb, it looks like crash in luajit lj_vm_cpuid fuction. |
| 04:18 |
SFENCE |
@sfan5 * |
| 04:51 |
SFENCE |
Same problem if I build Luanti 5.10.0 for x86_64 now. |
| 05:00 |
|
MTDiscord joined #luanti-dev |
| 05:18 |
|
SFENCE joined #luanti-dev |
| 06:44 |
|
BuckarooBanzai joined #luanti-dev |
| 06:50 |
|
Thomas-S joined #luanti-dev |
| 06:50 |
|
Thomas-S joined #luanti-dev |
| 07:34 |
|
SFENCE joined #luanti-dev |
| 07:57 |
|
hwpplayer1 joined #luanti-dev |
| 07:58 |
sfan5 |
that does sound like a luajit bug |
| 09:58 |
|
hwpplayer1 joined #luanti-dev |
| 11:15 |
ROllerozxa |
sfan5: someone is vandalising the serverlist |
| 11:17 |
ROllerozxa |
(they're currently bragging about it on the discord) |
| 11:18 |
sfan5 |
are schools on vacation again |
| 11:21 |
ROllerozxa |
lol, probably |
| 11:26 |
|
hwpplayer1 joined #luanti-dev |
| 13:22 |
|
Desour joined #luanti-dev |
| 14:09 |
MTDiscord |
<astra008.> I was not bragging, my was of expression was not right. I deleted a few messages and edited some. The thing I learned is that I should think before writing ✍️ |
| 14:58 |
|
SFENCE joined #luanti-dev |
| 14:59 |
|
SFENCE_arch joined #luanti-dev |
| 15:20 |
|
siliconsniffer joined #luanti-dev |
| 15:34 |
|
SFENCE joined #luanti-dev |
| 16:01 |
|
SFENCE joined #luanti-dev |
| 17:30 |
|
Desour joined #luanti-dev |
| 17:39 |
SFENCE |
@sfan5 I would not say luajit bug for sure. It happens also with same version of luajit, I used for compilation of Luanti 5.10.0. |
| 17:58 |
ROllerozxa |
sfan5: what happened with the deprecation phase for this in the serverlist: https://github.com/luanti-org/serverlist/blob/master/server.py#L459 |
| 17:58 |
ROllerozxa |
maybe I should take this privately but the pandora's box seems to be wide open now and I suspect that's what is being exploited |
| 18:01 |
celeron55 |
there's a discussion about that... well, i've lost the link, but if the kids are going to do this, then obviously there will be a response, and the response won't be nice to everyone. some legit servers are invalid with that check |
| 18:01 |
MTDiscord |
<luatic> yep |
| 18:02 |
MTDiscord |
<bastrabun> Which ones? Can't we just tell them and have them fix whatever misconfiguration causes this invalidity? |
| 18:03 |
celeron55 |
i recall it appears some indeed can fix it, but some can't, mainly the ones using a proxy server |
| 18:04 |
MTDiscord |
<warr1024> To know which ones, you might have to record that information for analysis on the server list itself. |
| 18:04 |
celeron55 |
we need the link |
| 18:04 |
MTDiscord |
<luatic> i mean, even fixing the impersonation issue, e.g. by asking the server to verify the announce, or checking the IP from which the request came, doesn't suffice to fix the problem of people being able to spam the serverlist with fresh announces with fake data which will get high scores |
| 18:04 |
celeron55 |
https://github.com/orgs/luanti-org/discussions/125 |
| 18:04 |
MTDiscord |
<warr1024> An IP address is not a very good authentication mechanism. |
| 18:04 |
celeron55 |
sfan5 published the list there |
| 18:05 |
celeron55 |
(that is the link i was referring to) |
| 18:05 |
MTDiscord |
<luatic> celeron55: that discussion is private btw |
| 18:05 |
MTDiscord |
<warr1024> 404 link |
| 18:07 |
celeron55 |
well that's another problem entirely |
| 18:07 |
celeron55 |
should there be a team on github with miscellaneous people in it that should have access to the org discussions? |
| 18:08 |
celeron55 |
anwyay, it's true that this won't prevent everything |
| 18:09 |
celeron55 |
it's stupid that the kids think they're smart and they're using an exploit we didn't think of |
| 18:10 |
celeron55 |
it's well known and intentionally left like that, to the benefit of users |
| 18:11 |
MTDiscord |
<warr1024> The ability of somebody to announce from a different IP address is a feature; the ability to announce against the server owner's will and alter the metadata is a design flaw. |
| 18:11 |
MTDiscord |
<warr1024> Using something like a single-use token or a zero-knowledge proof or something for the ping to verify the announcement metadata would be a safer way to handle this. |
| 18:12 |
celeron55 |
well that is true |
| 18:12 |
MTDiscord |
<warr1024> Or just have the announce HTTP request contain ONLY the address info, and ask the server for the metadata (and confirmation it wants to be listed) in the ping itself, via like an "ANNOUNCE_METADATA" packet or something that returns the JSON string in a packet if announce is enabled. |
| 18:12 |
celeron55 |
so you're suggesting the announce should contain a token, and when the serverlist pings a server, it should include the token and ask "is this yours?" |
| 18:13 |
celeron55 |
sfan5: you probably should give your opinion on this |
| 18:33 |
sfan5 |
workable, but won't fix the problem unless we drop compatibility. also who will implement it? |
| 18:36 |
MTDiscord |
<warr1024> I guess for the compatibility thing, we could go with IP address matching as the fallback. I don't like it (IP addresses are not to be trusted) but it'd be a reasonable mitigation. |
| 18:37 |
MTDiscord |
<warr1024> So like, a server verification thing would work for like 5% of people who early adopt, IP matching would catch like 90% of people who don't, and the last few who are on weird setups where their IPs don't match would at least have an option to adopt the protocol changes to make it work. |
| 18:38 |
MTDiscord |
<warr1024> If they're really insistent on running an older version or something, then I suppose they'd just have to care enough to backport it. |
| 18:41 |
celeron55 |
so what the serverlist should do is to check if the announce is supplying the token. if not, check the ip. if it gives a token, use the token to ask the server. the logic makes sense, but of course has to be implemented before it can exist |
| 18:43 |
jonadab |
You could of course implement the check, announce that old versions without the check (or a backport thereof) will become unsupported at some specific point in the future, and leave the problem unsolved ad interim. |
| 18:44 |
jonadab |
And by "unsupported" here we only mean unsupported by the main serverlist. |
| 18:45 |
jonadab |
People who know the server's address, or obtain it in some other way, would still be able to connect. |
| 18:45 |
jonadab |
And yes, the IP check as a fallback is still compatible with this. |
| 18:47 |
jonadab |
My inclination would be to make the specific point in the future, as far into the future as you dare, erring on the side of giving people plenty of time to update or patch. But that's a judgement call. |
| 18:49 |
jonadab |
You could *even* just sort all the verified ones to the beginning of the list (and give them a green checkmark and the others a red question mark or something). |
| 18:49 |
MTDiscord |
<warr1024> So by "use the token to ask the server", you mean the serverlist sends the token to the luanti server, and the luanti server naks the request if it gets a token but the token does not match? That sounds like it should work to me. |
| 18:51 |
jonadab |
If you're going to do it, have the server use its private key to sign a (random or pseudorandom) string that you supply with the token. |
| 18:51 |
jonadab |
Then it's hard to fake. |
| 18:52 |
MTDiscord |
<warr1024> That's the kind of solution I thought of at first, but validating the cryptographic soundness of that plan, let alone actually correctly implementing it, is a fair amount of work, while just using a shared secret random nonce token is simpler and good enough to have prevented the current crisis. |
| 18:53 |
MTDiscord |
<warr1024> As long as the tokens are rotated and a server can't easily be tricked into sending its announce to the wrong host (which TLS is supposed to be able to prevent) then the random token system should be good enough to give us a lot of time to think of whether/how we want to do something fancier. |
| 18:56 |
|
SFENCE joined #luanti-dev |
| 19:20 |
Desour |
for better compatibility, the server list could also keep track which servers announced with their luanti server ip, and only not allow updates from other ips for these servers |
| 19:22 |
Desour |
and the same for the token that you send to the server (which is also important to prevent ip spoofing), the servers who didnt use it in the first place could be handled without the checks. then attackers could only mess with servers that don't do the new authenticity stuff |
| 19:44 |
MTDiscord |
<warr1024> IIRC all servers have to include their address in the announcement. I think that's what we're already proposing: use the token if we can, try to use the IP if we can't. I don't think we can fall back past both the token AND address match though, or else that just disables all auth mechanisms and leaves us where we are now. |
| 19:44 |
MTDiscord |
<warr1024> There isn't currently a way for a server to opt in to address validation, and there especially isn't a way to do it that's not just subject to a trivial downgrade attack. |
| 23:34 |
|
panwolfram joined #luanti-dev |
| 23:58 |
rubenwardy |
sfan5: did you mean to touch ContentDB's weblate? It was reset to master yesterday |
