~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@zzz
+Hikari
+Minogami
+Unbur
+Xeha
+acetone
+profetikla
+snex
+uop23ip
+weko
An0nm0n
Arch
DeltaOreo
FreefallHeavens
Gid
Irc2PGuest13871
Irc2PGuest2974
Leopold
Liorar_
Nausicaa
Onn4l7h
StormyCloudInc
admin
anon
anontor
anu
cheddah
itsjustme
limak
not_bob_afk
poriori_
qend-irc2p_
u5657
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.
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.
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