#asciilifeform | 2020-07-30

Apocalyptic: how the hell is this a vuln ? 'secure boot' is elementary fritzchip (i.e. 'secure against owner')

↖

00:36

this nonsense is rather like crapple's regular 'ohnoez, jailbreak found again, security vuln!'

00:37

( see also. )

00:37

Logged on 2020-05-05 12:51:05 asciilifeform: violadivias: the 'attack resistance' in the linked piece is an artful distraction/disinfo. cr50 is there specifically to prevent the owner of the machine from getting 100% control over it.

00:38

my understanding is that the buffer overflow is independent from 'SecureBoot', but enabling the attack, still lulzy though

00:39

'attack' against what, though

00:39

it's a jailbreak, for jailed pcs (which,sadly, exist..)

00:40

against the whole "signed by CAs" shitshow that occurs in SecureBoot, supposedly

00:40

well yes. i.e. jailed pc.

00:41

"To dig a little deeper into the vulnerability itself, we’ll take a closer look at how the code works internally. In order to process commands from the external configuration file, GRUB2 uses flex and bison to generate a parsing engine for a domain-specific language (DSL) from language description files and helper functions." this also is telling what a pile of shit grub2 is

00:42

Apocalyptic: it was titanic pile o'shit for almost whole time it existed. there's e.g. ttf glyph renderer, and fuckknows what else in there

00:42

MBs of liquishit

00:43

and, evidently, native support for microshit's formerly-'palladium' 'you dun own yer pc' attempts.

00:44

*

asciilifeform got 'grub' the fuck off all personally-owned and supported iron yrs ago

00:44

*

asciilifeform also doesn't buy palladiumized irons.

00:45

i still gotta lul over the typical attempt to spin a jailbreak as a 'vulnerability' tho

00:45

iirc intel did same when 'ME' 0day 1st published .

00:46

*

asciilifeform bbl.

00:48

asciilifeform, you switched to lilo on all irons ?

~ 10 hours 27 minutes ~

11:16

Apocalyptic: all the x86+linux irons i had in active service, afaik. most of them did not have to switch, set up with it at start.

11:16

!w poll

11:16

Polling 12 nodes...

11:16

205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.085s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=641484

11:16

205.134.172.6:8333 : (172-6.core.ai.net) Alive: (0.082s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=641484

11:16

205.134.172.27:8333 : Alive: (0.124s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=641484 (Operator: asciilifeform)

11:16

205.134.172.26:8333 : Alive: (0.124s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=641484

11:16

108.31.170.3:8333 : (pool-108-31-170-3.washdc.fios.verizon.net) Alive: (0.110s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=641484 (Operator: asciilifeform)

11:16

192.151.158.26:8333 : Alive: (0.132s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=641484

11:16

208.94.240.42:8333 : Alive: (0.202s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=641484

11:16

143.202.160.10:8333 : Alive: (0.221s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=641484

11:16

213.109.238.156:8333 : Alive: (0.392s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=641484

11:16

188.121.168.69:8333 : (rev-188-121-168-69.radiolan.sk) Alive: (0.374s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=641484

11:16

176.9.59.199:8333 : Busy? (No answer in 20 sec.) (Operator: jurov)

11:16

103.36.92.112:8333 : Busy? (No answer in 20 sec.)

~ 1 hours 55 minutes ~

13:12

!q uptime

13:12

asciilifeform: time since my last reconnect : 0d 0h 0m

13:13

pretty interesting -- found that bot was hung. 1st detectable instance of this since wrote it.

13:13

aaand it was still receiving 'pings' from fleanode..

13:14

*

asciilifeform suspects problem on fleanoad end

13:14

makes trinque's algo seem appealing.

13:14

Logged on 2020-07-29 11:55:49 trinque: even considered having a pair of twins bot deployment which chatter to each other to confirm connection, rather than trusting that someone on the server side PONGed

13:26

!q uptime

13:26

asciilifeform: time since my last reconnect : 0d 0h 14m

~ 30 minutes ~

13:57

!q uptime

13:57

asciilifeform: time since my last reconnect : 0d 0h 45m

~ 23 minutes ~

14:21

feedbot

http://thetarpit.org/2020/briefly-on-programming-irc-bots-using-common-lisp << The Tar Pit -- Briefly, on programming IRC bots using Common Lisp

14:28

^ hey spyked :

14:28

what'd be wrong with , e.g. :

14:28

(defmacro if-timeout (timeout timeout-form &body body)

14:28

"Return timeout-form if timeout times out, otherwise return result of body."

14:28

`(handler-case (bordeaux-threads:with-timeout (,timeout)

14:28

,@body)

14:28

(condition (bordeaux-threads:timeout)

14:28

(declare (ignore timeout))

14:28

,timeout-form)))

14:28

and then, e.g. :

14:29

(if-timeout *your-timeout* (format yer-log "eggog...") (progn (.........) ))

14:30

on top of this, the python example is 100% synchronous, and doesn't even require this kinda thing -- 'except socket.timeout' gets thrown if recv() actually returns timeout eggog code, strictly

~ 1 hours 1 minutes ~

15:32

ACHTUNG, readers! logotron updated with sane date handling for next/prev (i.e. skips empty days, but behaves correctly if these are req'd manually.) plox to report bugs ! will later issue vpatch.

15:33

includes also 'dawn of time' handling ( example . )

~ 35 minutes ~

16:09

logotron homepage updated w/ vpatch!

~ 1 hours 11 minutes ~

17:21