Show Idle (>14 d.) Chans


← 2022-12-26 | 2022-12-28 →
awt[asciilifeform]: http://logs.bitdash.io/pest/2022-10-05#1013925 << afaict this hypothesis was incorrect. % commands are only processed from the operator.
bitbot[asciilifeform]: Logged on 2022-10-05 16:25:36 asciilifeform[5]: looking in awt's client.py, saw 'notice_and_privmsg_handler()', where in fact looks for pest cmds in... privmsg's from ~both~ directions?! wai?!~!
awt[asciilifeform]: My current understanding is that the bug jonsykkel successfully exploited was that blatta doesn't escape incoming messages for irc commands.
jonsykkel[asciilifeform]: yes iirc %commands didnt have an efect
awt[asciilifeform]: jonsykkel: how do you escape incoming messages?
jonsykkel[asciilifeform]: was rather irc comands ie \r\n:part #pest someone
jonsykkel[asciilifeform]: awt: i just reject if contains \r or \n
jonsykkel[asciilifeform]: cant remember if spec says anyhting re this
awt[asciilifeform]: jonsykkel: yes I don't recall if multiline messages are allowed.
phf[asciilifeform]: http://logs.nosuchlabs.com/log/pest/2022-12-27#1019516 << not sure which bug jonsykkel exploited, but the bug that you quoted, and asciilifeform made a hypotheses about was later exploited by me, and i also provide an explanation
dulapbot: Logged on 2022-12-27 09:06:11 awt[asciilifeform]: My current understanding is that the bug jonsykkel successfully exploited was that blatta doesn't escape incoming messages for irc commands.
phf[asciilifeform]: actually maybe i didn't explain it, tthe bug is that pest allows newlines in messages, but irc protocol doesn't. so if you simply passthrough a message with newline, everything after newline becomes part of stream from pest to irc client
phf[asciilifeform]: i think the correct solution is to split a pest message by newlines, and send each line as a separate privmsg to client
awt[asciilifeform]: phf: hm yes that makes sense.
awt[asciilifeform]: http://logs.bitdash.io/pest/2022-12-27#1019456 << asciilifeform's report was that blatta was looking for *pest* commands in incoming messages, which is not the case.
bitbot[asciilifeform]: Logged on 2022-12-27 10:37:33 phf[awt]: http://logs.nosuchlabs.com/log/pest/2022-12-27#1019516 << not sure which bug jonsykkel exploited, but the bug that you quoted, and asciilifeform made a hypotheses about was later exploited by me, and i also provide an explanation
dulapbot: Logged on 2022-12-27 09:06:11 awt[asciilifeform]: My current understanding is that the bug jonsykkel successfully exploited was that blatta doesn't escape incoming messages for irc commands.
phf[asciilifeform]: his report was an invalid interpretation of the same original bug log we both looked at, and at least as far as that log is concerned, his interpretation was invalid
bitbot[asciilifeform]: Logged on 2022-10-05 16:17:44 asciilifeform[6]: in otherlulz, lulzy sideffects of yest.'s blatta bugola.
bitbot[asciilifeform]: Logged on 2022-12-27 10:39:49 phf[awt]: actually maybe i didn't explain it, tthe bug is that pest allows newlines in messages, but irc protocol doesn't. so if you simply passthrough a message with newline, everything after newline becomes part of stream from pest to irc client
awt[asciilifeform]: Ah yes ok - missed that paste.
busybot: The 24-Hour VWAP for BTC is $ 16760.35 USD
phf[asciilifeform]: ah jonsykkel's exploitation is the same one http://logs.bitdash.io/pest/2022-10-05#1013992
bitbot[asciilifeform]: Logged on 2022-10-05 19:38:06 phf[awt]: fyi http://glyf.org/screenshots/pest-multiline.png
asciilifeform: http://logs.bitdash.io/pest/2022-12-27#1019461 << possibly asciilifeform is thick, but from notice_and_privmsg_handler() still appears that 'if message[0] == "%"' kicks in regardless of what direction message is going (irc->pestron or reverse) ?
bitbot[asciilifeform]: Logged on 2022-12-27 10:45:30 awt: http://logs.bitdash.io/pest/2022-12-27#1019456 << asciilifeform's report was that blatta was looking for *pest* commands in incoming messages, which is not the case.
asciilifeform: still needs the newline thing to set it off, cuz otherwise the '%'-prefixed incoming msg doesn't match any useful command, afaik
phf[asciilifeform]: poc or gtfo?
asciilifeform looks again at phf's description of his poc
asciilifeform unfortunately does not atm have a phf-style hand-cranked pest packet shooter handy
asciilifeform: iirc jonsykkel tried sending msgs with '%' at pos0, asciilifeform saw invalid cmd barf in local log then
asciilifeform: phf: if you've the cycles, can plox send out e.g. '%at' ?
phf[asciilifeform]: i'm not playing this game again, you'r interpretation is incorrect
asciilifeform: awt: what am i missing re the pasted py routine ? from jonsykkel above, clear that it doesn't behave as asciilifeform supposed, but not obv wai
asciilifeform: %peer stalin
asciilifeform: phf: yer quite evidently right that it was 'red herring', but would like to know why
asciilifeform: lol jonsykkel what didja do there ?
asciilifeform: 13:15:02 asciilifeform | %peer stalin
jonsykkel[asciilifeform]: asciilifeform: \r\n trick
asciilifeform: as phf described
asciilifeform: but '%' trick dun work, even tho seems that oughta from the coad. asciilifeform insufficient pythonist to see why, tho
asciilifeform: http://logs.bitdash.io/pest/2022-12-27#1019459 << imho oughta terminate at newline, rather than split (maintain 1:1 pest msg to irc msg) but possibly not matters if the irc frontend is 1foot in grave already
bitbot[asciilifeform]: Logged on 2022-12-27 10:40:15 phf[awt]: i think the correct solution is to split a pest message by newlines, and send each line as a separate privmsg to client
phf: that means that entirely valid multiline pest messages will result in information loss on irc clients
phf: http://logs.nosuchlabs.com/log/pest/2022-12-27#1019560 << but that's nothing to do with python. the only place where irc pest ought to be parsing privmsg's in general is when receiving from irc client of the station operator, so it makes sense for there to be only one handler, hardcoded for message[0]=='%' etc
dulapbot: Logged on 2022-12-27 13:16:32 asciilifeform: but '%' trick dun work, even tho seems that oughta from the coad. asciilifeform insufficient pythonist to see why, tho
asciilifeform: phf: tru
asciilifeform not much cares in either direction; irc frontend 'delenda est' imho
asciilifeform[busybot]: either is over9000x better than the old behaviour tho
phf[asciilifeform]: i have an ugly hack in my pest, which makes messages->
phf[asciilifeform]: whoops, i used wrong broadcast function..
phf[asciilifeform]: i have an ugly hack in my pest, which makes messages->
phf: like this into mutliple pest messages. i'd like to remove it and send->
phf[busybot]: proper multline messages instead :>
awt[asciilifeform]: http://logs.bitdash.io/pest/2022-12-27#1019493 << Doesn't work because incoming messages all go to the __writebuffer variable which goes directly to the client and doesn't feed into notice_and_privmsg_handler().
bitbot[phf]: Logged on 2022-12-27 13:17:42 asciilifeform[6]: but '%' trick dun work, even tho seems that oughta from the coad. asciilifeform insufficient pythonist to see why, tho
← 2022-12-26 | 2022-12-28 →