#saltr (irc2p) | I2P+ 2.7.0-10+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

dr|z3d arstechnica.i2p/tech-policy/2023/04/fbi-rent-a-hitman-site-nabbed-air-national-guardsman-who-was-excited-to-kill

dr|z3d "Garcia allegedly told an undercover agent that he would be comfortable torturing victims and taking trophies such as fingers or ears, that he owned an AR-15 rifle, and that he accepted an envelope with $2,500 in cash as a down payment for killing the fictional client's abusive husband."

obscuratus dr|z3d: A user in #i2p and #i2p-chat (<xeiaso_>) has been cross posting an allegation of an I2P de-anonymization bug.

obscuratus I'm not sure there's any merit to it, but I hate to leave allegation hanging out there.

dr|z3d obscuratus: yeah, RN informed me. I've passed the link over to orignal

obscuratus I started a issue here: git.idk.i2p/i2p-hackers/i2p.i2p/-/issues/397

dr|z3d Smells like prime bullshit to me.

dr|z3d Of all the places to post a possible bug, an image board isn't one of them. Unless you're trying to impress your teenage buddies.

obscuratus I don't see the de-anonymization. If target=<us> and tunnelid=null, all your doing is saying "Yes, I am the I2P router at this address".

obscuratus That's not de-anonymization. everyone already knows this.

obscuratus If the target was a lease-set, that would be another story.

dr|z3d It's a lot of noise and not much else afaict.

dr|z3d That and a less than stellar grasp of the router internals.

dr|z3d there's even some commented text further down..

dr|z3d // ok, they want us to send it remotely, but that'd bust our anonymity,

dr|z3d // so we send it out a tunnel first

dr|z3d // TODO use the OCMOSJ cache to pick OB tunnel we are already using?

dr|z3d are you working on anything code-wise, obscuratus?

obscuratus dr|z3d: Errr, so, as it turns out, I'd already been looking at this snippet of code. Back on Feb. 8, when we were having all kinds of "attacks", I added some debugging at that spot in InboundMessageDistributor.java.

obscuratus I'd back-burnered it. I thought we addressed the issues I was looking at.

dr|z3d anything useful in the debug logs?

obscuratus But, I added some debugging around that spot, and I'm going back and looking at some of the result I'm seeing now if I activate that debugging.

obscuratus There's a surprising amount of traffic that goes through that spot.

obscuratus Most of it is target: Null and Tunnelid" Null

dr|z3d interesting. either malformed packets, perhaps, or something more sinister.

dr|z3d could be a half-baked, buggy implementation.

obscuratus It's hard to follow the flow. When the message is distrubited, it goes to another thread. There's always a torrent of garlic messages, and you have a break that makes it difficult to associate the message with this section of code.

RN so, your'e saying, it is obscure?

obscuratus So much was going on back in February, I'm trying to remember what I was even looking at then.

obscuratus RN: :)

RN Σ:Đ

dr|z3d don't encourage her :)

RN :þ

obscuratus her?

obscuratus It's a mystery.

dr|z3d her as in female gender.

dr|z3d aka "her" :)

obscuratus But I have my opinions.

obscuratus :)

obscuratus It's a tricky section of code. You receive a garlic message from who-knows-where, and have some structure for how to pass it through.

dr|z3d sure, there's probably a certain amount of intention in the obscurity of the message path.

obscuratus So, I guess the allegation is: Can someone directly send you a garlic message through the mentions portion of code, and then be received as a destination that is supposed to be obfuscated.

obscuratus So they send a messsage directly, but disguise it as addressed to a tunnel destination.

obscuratus I don't think we work that way. But that seems to be the allegation.

obscuratus dr|z3d: xeiaso__ is asking for voice.

dr|z3d voice him up :)

xeiaso__ thanks

xeiaso__ It's the other way round. Sent to a destination, but the if statement compares it to the router.

xeiaso__ And target and tunnel both being null is normal

obscuratus OK, should be easier. Audit the code to make sure "target" can't be a destination. I *THINK* target can only be a router distination.

xeiaso__ "target" is whatever the person crafting the packet wants it to be

obscuratus So, router destination is different from a tunnel destination.

obscuratus I hope. :)

xeiaso__ target could be *anything*

obscuratus xeiaso__: I think the two are inherently different, but we should audit the code to make sure.

xeiaso__ the two are both hashes

obscuratus I don't think you can pass target as a tunnel destination and mean anything.

xeiaso__ 32 bytes

xeiaso__ Target doesn't need to be passed anywhere. Just compared to the router hash.

obscuratus xeiaso__: Just because they're the same size doesn't mean they're handled the same.

obscuratus xeiaso__: OK, so you send a message to the router hash, and it replies that: "Yes I'm that router hash". That doesn't leak anything that's not already known.

xeiaso__ No, you sent a message to a destination and you hear back.

obscuratus Then tunnel_id wouldn't be null.

xeiaso__ tunnel id is read from a packet

obscuratus OK, so you send a message down my anonymized IRC tunnel, with my router as the destination, and we would acknowledge?

obscuratus In this case, neither tunnel_id is null, nor the destination.

xeiaso__ The IBGW of your tunnel normally decides to sent it with target == null and tunnel == null

xeiaso__ But it can do whatever the hell it wants

xeiaso__ It can sent the packet down the tunnel with target == <your router> and tunnel == null

xeiaso__ So pretty much, yes.

obscuratus xeiaso__: OK, helpfull. So the scenario is we receive a message down a tunnel associated with us (such as our IRC tunnel). We get confused and acknowledge that we are actually the router at the end of this tunnel, which is suppoese to be hidden.

xeiaso__ Yes.

xeiaso__ dr|z3d: Someone asked this #i2p:

xeiaso__ >does anyone known if there will be an 2.2.1+ update soon for i2p+? My router accidentally updated to 2.2.1. In the meantime, would it not be a bad idea to go back since this update doesn't have that many crucial fixes in my case at least?

dr|z3d xeiaso__: they can just pull the latest update.zip manually, copy to their app dir and all will be good. there's no imminent 2.2.1+

obscuratus I *think* the tunnel variable is the inbound tunnel, so it wouldn't be null.

dr|z3d skank.i2p/dev/i2pupdate.zip

xeiaso__ Look on line 52. "tunnel" is a TunnelId.

obscuratus xeiaso__: Anyhow, thanks, that was specific, and we can audit for that scenario.

obscuratus xeiaso__: That has to be the inbound tunnel. We don't even know the outbound tunnel until we decrypt the message, which we haven't done yet.

dr|z3d xeiaso__: alternatively, depending on when they updated to the vanilla i2p, they might just be able to check for updates on /configupdate and find a new I2P+ update

dr|z3d they could also hop in here for help :)

RN I've been encouraging them to drop in here... they got scared away before becaus they didn't have voice, and they're kinda new to irc

xeiaso__ Yes, this is at the end of an inbound tunnel.

dr|z3d you can voice them when they come in, RN. you have the power :)

RN that was the plan

dr|z3d well, if they're using I2P+ and having issues updating, they should be hanging out here. tickle them this way. :)

dr|z3d the update to canon when I didn't want to in I2P+ should be fixed in the latest builds, btw.

obscuratus xeiaso__: So, you're speculating that you can craft a malevolent router (not at all impossible) that will target a tunnel, such as an IRC tunnel, and run messages down it with random specific router destinations, and see if one hits?

xeiaso__ Yes.

xeiaso__ And you can try as many times as you want.

obscuratus OK, we can audit the Inbound Message Distrubitor, and see if that's possible.

dr|z3d have they registered to nickserv, RN?

obscuratus But, at first glance, that's not the section of code highlighted by lambdaplusjs. Neither tunnel_id or target is NULL in this scenario.

xeiaso__ 39096?

xeiaso__ The only Java I2P code highlighted contains "_context.routerHash().equals(target)".

xeiaso__ In any scenario, the IBGW chooses the delivery instructions.

RN yeah, they just haven't joined here

obscuratus xeiaso__: You only get to "_context.routerHash().equals(target)" if target=NULL and tunnel=NULL, right?

xeiaso__ No.

xeiaso__ What prevents them not both being null?

dr|z3d you should probably register your nick, too, xeiaso__

dr|z3d Blinded message

xeiaso__ I thought I already did that.

dr|z3d apparently not, at least not on that nick. try removing the __

dr|z3d also see /msg nickserv help group

obscuratus xeiaso: OK, so we receive a stray message down our IRC tunnel, with the intent of tricking us to divulge that we are router <Us>. We'll need to look at that.

obscuratus But, I'm not seeing it right off.

xeiaso If the router isn't <us>, our stray message doesn't make it to the destination.

xeiaso But if it is <us>, then the destination gets out message.

obscuratus But it's coming down a tunnel, so tunnel!=NULL

xeiaso Wrong. The tunnel variable is a TunnelId and may be null.

obscuratus And if it only makes sense if target==<us>.

xeiaso It only reaches the destination if target==<us>

obscuratus HHmmm, so we receive a message down our IRC tunnel, but the IBMD sees it a tunnel==NULL?

xeiaso Yes.

obscuratus Remember, tunnel is the source tunnel, we don't even know the dest tunnel (if there is one) yet.

xeiaso What do you mean by source tunnel?

obscuratus Such as an IRC tunnel.

xeiaso Right, so an IRC tunnel that belongs to an IRC destination.

obscuratus yes

obscuratus destination is the wrong term, because it actually inbound. But I think we're talking about the same thing.

obscuratus From the perspective of the attacker, yes, it's a destination.

xeiaso inbound tunnel to our destination

xeiaso destination being an addressable thing

obscuratus Yes, and supposedly anonymous

xeiaso hopefully anonymous :^)

obscuratus :)

obscuratus I don't think we receive a message down a tunnel without the IMDB tunnel being "NOT NULL".

xeiaso Not normally. But not necessarily.

RN IMDB? or IBGW?

obscuratus Argh, I mean Inbount Message Distrubutor.

obscuratus IBMD

obscuratus xeiaso: I think it is necessarily, be we can check that assumption/assertion.

xeiaso Tunnels, both inbound and outbound, use the same delivery instruction format.

xeiaso geti2p.net/spec/tunnel-message#first-fragment-delivery-instructions

obscuratus Can a message come down a tunnel to the IBMD with tunnel still being NULL? I assume no, but that's auditable.

xeiaso It's just by convention the IBGW only sends LOCAL delivery type

obscuratus And just to clarify, I do see a lot of messages with target==NULL and tunnel==NULL

xeiaso Yes that's normal.

obscuratus xeiaso: You seem like you've poked around this stuff considerably. :)

xeiaso Not a lot. Just enough to follow along the flow of some packets.

obscuratus I've started an issue at git.idk.i2p/i2p-hackers/i2p.i2p/-/issues/397

obscuratus please feel free to comment there.

obscuratus xeiaso: The number of people who can follow packets are quite rare. Good Job. :)

xeiaso My day job is at a packet handling company after all :)

obscuratus I/We will have to try to figure out how a packet can come down a tunnel, and have the variable "tunnel" == NULL in the IBMD.

xeiaso Line 376 uses the target and tunnel id from a garlic clove.

xeiaso That is 100% under the control of an adversary

obscuratus ? distribute(data, instructions.getRouter(), instructions.getTunnelId());

xeiaso That's it.

xeiaso Has anyone notified orignal about this?

dr|z3d he's been informed of your image board post. which, while we're on the subject, is just about the worst place to post if you want to be taken seriously.

xeiaso Well, I found it at least.

xeiaso and what do you mean by "your"?

xeiaso *you

dr|z3d your image board post. presumably that was you posting to the tor image board?

xeiaso No. I came across it and brought it up here.

dr|z3d oh, sorry, I thought you were the poster.

dr|z3d anyways, a belated welcome to the channel, and indeed the network if you're new here :)

xeiaso Here's a thought experiment: Mallory sends a letter that starts with "Dear Alice" to P.O. box X. Mallory receives no reply. She repeats the process but starts the letter with "Dear Bob". Still no reply. But when she starts the letter with "Dear Carol" she gets a reply in the mail that says "Dear Mallory, thank you for your letter. Signed P.O. box X". Mallory concludes that Carol is the one behind P.O. box X. How

xeiaso does Mallory know this?

eyedeekay I'm still not convinced of the basic thing, that carol will reply at all

RN Carol is on spring break holiday. Good luck getting a reply.

obscuratus Hhhmm, are all the paste bins down?

eyedeekay Mine is, cake should be up though

dr|z3d yeah, cake's good.

dr|z3d welcome back, eyedeekay

dr|z3d cake's also good if you want to add some free syntax highlighting, assuming you have a file that qualifies for the treatment

eyedeekay Thanks doc

dr|z3d I got an idea for you I've been thinking about for a while, eyedeekay

dr|z3d A console-wide api for UI form elements.. radios, checkboxes and dropdowns etc.

dr|z3d snark ui options are more or less workable, but the console is an absolute nuisance to add any ui stuff to when it comes to form elements.

dr|z3d one might argue that the ui is already fairly well provisioned, UI-wise, but I'd counter and say that there are plenty of options that would work nicely in the UI in advanced mode on the /configadvanced page, for example.

eyedeekay dr|zed that's an interesting take but is there any extant system for this we could use/adapt? Or is our system too intractable to do that and we must ryo?

eyedeekay 10,99eyedeekay:99,99 dr|zed that's an interesting take but is there any extant system for this we could use/adapt? Or is our system too intractable to do that and we must ryo?

dr|z3d good question, eyedeekay

dr|z3d something like formio.net/index.html perhaps?

eyedeekay Yeah exactly something like that

eyedeekay Probably a non-zero migration effort, but maybe with payoffs in the end

dr|z3d yeah, we'd probably want to use it for new stuff initially to reduce the workload, and then migrate existing stuff over time, no?

dr|z3d wouldn't want to tackle all the existing stuff in one go. that would be work++

dr|z3d anyways, good documentation, seems reasonably well maintained.

eyedeekay Maybe, but I am thinking about what I want from a move like that and what I want, and what I want is to make working on extant apps easier, so maybe we pick one and migrate it as an experiment

dr|z3d sure, sounds like a good starting point. maybe susimail is a good candidate.

dr|z3d not too much going on in the UI there, and you're already looking at it.

dr|z3d or we could just choose a single page in the console and tackle that.

eyedeekay Fringe benefits to such a migration, too, there are a lot of checks in susimail that might become clearer if the UI were done differently

dr|z3d no doubt. susimail could do with some abstraction, it's super old and hasn't been touched much in the last 15y.

dr|z3d that monolithic WebMail.java I'm thinking of specifically. would be handy to pull some of that out into jsps.

eyedeekay Yeah to say the least, been picking it(WebMail.java) apart over here and I basically don't think I can do anything well until I can turn that unto jsp

eyedeekay *into

dr|z3d might be handy to start with i2p+'s mods, dunno. see if that's a better starting point.

dr|z3d things like being able to see the mail headers without viewing the page source never hurt :)

dr|z3d there's another thing you might want to do, easy win. do a global search and replace for trailing spaces :)

dr|z3d guaranteed not to break anything, I did that on the i2p+ codebase a long time ago.

end50 Hey, I finally have voice! That's nice.

end50 I got here from the I2P+ main menu, in fact I'm pretty new to I2P itself.

dr|z3d welcome, welcome. for extra points, you may wish to register your nick via /msg nickserv register choose_a_password fake@mail.com

dr|z3d new is good. we were all new once :)

end50 Oh, I might as well get an i2p email address then.

dr|z3d you can supply a fake address, it's only used for password recovery (if a correct one is supplied).

dr|z3d that said, no harm in getting yourself an @mail.i2p address.

dr|z3d which can also be addressed as @i2pmail.org for clearnet communication.

dr|z3d was it you who RN mentioned having an issue with i2p+ updates?

end50 That's cool. I use keepassXC so I do not actually need any recovery, but since I find I2P to be very cool I plan on getting an address.

end50 And no, it wasn't me.

dr|z3d ok

end50 By the way, since I'm new, I wanted to ask is there anything I should know about I2P that I'm not aware of already? Any tips and/or tricks that may be useful to me?

dr|z3d I was going to say, some people forget to enable the update checker for i2p+ on /configupdate

end50 Already done so not an issue.

dr|z3d well, we don't know what you're aware of, so hard to say :)

end50 In fact, barely anything

dr|z3d if you like the rolling-release type approach, the /dev/ url is recommended.

end50 I'm fine with stable.

dr|z3d ok

end50 I do plan on browsing I2P a lot more and learning how it works and stuff, been a good while since I have been this interested in something.

dr|z3d the stable url will occasionally update with point releases if there's bug fixes or shiney new stuff that's tried and tested. not often, but sometimes.

end50 Got it.

dr|z3d well, if you haven't already had a good look around /help/ you should probably do that.

end50 Took me long enough to realize it was there, lol

dr|z3d :)

dr|z3d another thing you might not have noticed is the sortable tables in various places. if you hover over the table column headings, you'll be able to tell if the table is sortable.

dr|z3d collapsible sidepanel sections you've probably already worked out.

end50 I'll see, there are a lot of things to check out in the menu so it's a tad bit overwhelming

end50 I believe that's a good thing, though.

end50 I like overly-configurable things.

dr|z3d sure, takes some time to get a hang of things. don't forget tooltips, plenty of those around to help you navigate :)

end50 I am looking at the postman.i2p registration page but one of the rules say, "Delete your account, when you're done testing or finished playing around". What if I want to have the email indefinitely as a personal one?

end50 It's a bit vague. Confusing.

dr|z3d hq.postman.i2p ?

end50 Yup.

dr|z3d no need to delete your account, it's probably suggesting you do that _if_ you just want to test things out.

dr|z3d otherwise, your account will remain active while you use it. I think there's something like a once in 90 days requirement.

end50 That's understandable.

RN yes dr|z3d I did a while back... turned off auto...

RN also another user yestarday was asking about it

dr|z3d ok, RN, thanks, hopefully you resolved the issue for them.

RN yeah, they grabbed the updater file from skank

dr|z3d ok, great, thanks.

RN but then never took up on the invite to join here

RN [thumbs-up]

dr|z3d RN: if they register their nick before joining the channel, I'll auto-voice them when they join, if you want to relay that.

dr|z3d anyone with an i2pforum acct running I2P+ who wants to contribute to this thread, feel free. i2pforum.i2p/viewtopic.php?p=2721&sid=13a7f77d5698165ae77a4b3637ca5a1b#p2721

RN yep, they had a reg'd nick... just haven't seen them today