Subj : Re: Tutorial for rookies To : N1uro From : tenser Date : Thu Oct 14 2021 02:01 am On 13 Oct 2021 at 12:07a, N1uro pondered and said... N1> tenser; N1> N1> -=> tenser wrote to N1uro <=- N1> N1> te> On 12 Oct 2021 at 01:25p, N1uro pondered and said... N1> N1> te> If I ask for some data, and you cannot provide it, then yes, N1> te> I question your veracity. In particular, if this code is being N1> te> maintained and the issue in question isn't being effectively N1> te> tracked, how do you know it hasn't already been fixed? How do N1> te> you know that the people doing the maintenance are even aware? N1> N1> You've asked for data and I've done what I could and beyond to provide N1> it. I know who's maintaining the code in question as we email amongst N1> ourselves. We all share code. I know some code has been fixed, some yet N1> has been fixed. I'm hoping by year end it'll all be fixed. Actually, no: you said, "go read the linux-hams list and URONode list." That's not really any more useful than saying, "there are bugs." N1> te> I merely asked you for a pointer to a bug repository where these N1> te> issues were being tracked. That's not "hateful". You refused N1> te> to provide any details. Repeated refusals make me wonder if it's N1> te> really a problem. N1> N1> I have not refused answers. Specific details perhaps because of the fact N1> that it's not a good idea to let non-hams have information on how to N1> exploit ham boxes. You want these published however to which I can not N1> understand for the life of me why. I did point you to a more current N1> archive of linux-hams which you claimed did not exist. I corrected myself on linux-hams, but this makes no sense: if the information isn't "safe" for public disclosure, why point me to a public mailing list? If it's on the public mailing list, why make such a fuss about it here? You can't have it both ways. N1> te> You might consider showing some appreciation for people who are N1> te> interested in these things; who knows, they may be able to fix N1> te> some bugs. N1> N1> If you emailed me privately we could get into more details. In a public N1> echo area is not the place to discuss these things. I do appreciate N1> those who use such things, often it's me that gets the disrepect and N1> frankly I grow tired of it. If you had said, "I don't feel comfortable discussing it here, please email me" I would have done so. You did not. The "disrespect" you get seems earned, frankly. N1> te> Sounds like security through obscurity to me. Think of this way: N1> te> what's to prevent a ham from doing this _right now_, since these N1> te> problems are, as you claim, unsolved upstream. How would that ham N1> te> _even know_? By your own admission, this isn't even being tracked N1> te> anywhere. How would they possibly discover the issue? N1> N1> Publically it's not tracked. Privately yes. I don't believe you. The last message is the first you mentioned that it's _privately_ tracked. Given that it seems relevant, I find it odd that you haven't mentioned it until now. Given that your initial response was to point to a public mailing list, it strikes me as unlikely that there's some kind of super-secret "ham in the know" bug tracker for AX.25 issues. Further, I see no record of YO2LOJ's one-line patch making it to the LKML, though you suggested that it was due to "political" reasons that that patch hadn't been incorporated upstream. But the entire thing begs the question: Was it ever sent? N1> Many ham projects are tracked N1> securely via obscurity. That's not what "securely" means. N1> Why would I have a reason to say that sockets are N1> left open if it's not true? In what way(s) would I gain any benefit N1> either way? Zero! Strawman. I never suggested that you "gain" anything or that it wasn't true. N1> te> Your own statements that the project is not available on N1> te> sourceforge because of these kernel issues you continue to N1> te> talk about. N1> N1> Those who have used my software for the 20+ years it's been around know N1> me and know I would help them out. I don't want any new users at this N1> time but will help those who do grab it using apt or dnf to install them N1> with. 95% however when faced with having to compile a kernel or patch a N1> kernel usually will flee back to DOS. I am also in very poor health and N1> don't wish to be bothered by those who aren't willing to take the steps N1> needed. Those who do use my software will wait quite patiently for the N1> projects to be reposted with the upgrades in them. I'm not concerned. I'm sorry you are in poor health, but I've observed how you behave here, on the eastnet mailing list, and on the 44net mailing list for several years and I find your ego and constant persecution complex too much. It's great that you are not concerned that people won't be able to use your software, but I find your public projections unpleasant. N1> te> https://github.com/dancrossnyc/ N1> N1> Ahh now I know who you are. I assigned you your block and maintain your N1> ampr DNS. Considering the level of integrity I gave you to get you up and N1> running on 44-net, what reason did I offer you to prove not to believe N1> me? Again, I have nothing to gain either way here. Well, perhaps making self-contradictory and objectively false statements and then behaving like a spoiled child has something to do with it, not to mention your personal behavior. Given that you are in such poor health, perhaps you should consider stepping down as an AMPRNet coordinator. You can also delegate DNS to me so that it's not such a burden for you (or, frankly, me). N1> N1> Besides my own projects I also N1> N1> contribute to the LinFBB project. N1> N1> te> That's nice...? N1> N1> You could always also look inside the tickets of LinFBB on the afore N1> mentioned issues. So is it publicly tracked or privately? Also, you _could_ have mentioned this before instead of flying off the handle. N1> F6BVP and his crew supplied ROSE patches as the N1> URONode crew has supplied NetRom fixes. Others have supplied various N1> fixes to various codes. Some have to do with the ax25 libs some with the N1> kernel protocol stack. The ones I personally am most concerned about are N1> the 6-pack and NetRom bugs. Yeah, that's how open-source software works. N1> N1> I pulled my projects off sourceforge N1> N1> until such time as the kernel bugs are fixed. I'm simply tired with N1> N1> receiving emails asking me why my stuff "doesn't work" when I have th N1> N1> only node project available that works on old IBM emulation systems! N1> N1> te> This seems to directly contradict your statement above that your N1> te> didn't pull your projects off of sourceforge. N1> N1> I -said- I pulled them off, however various distros still have the N1> software in their repositories. So hams can install your software and "packet kiddies" can own their machines (and their licenses?) today with less effort than it takes to find and download your software from Sourceforge. Explain to me again how removing your projects from sourceforge helps keep anyone secure? N1> te> Cool. What guarantee do we have that you won't yank them again? N1> te> Once you establish a pattern of behavior, users and potential N1> te> users will recognize it for what it is and react accordingly. N1> N1> I have announced that once the issues are fixed they'll be back. My N1> core base knows that I'll hold true to my word. Hopefully the stack N1> issues once fixed will remain fixed TFN. It seems as if some of these N1> bugs have been in existence since the 1990s however just weren't noticed I suspect that if your "core base" had an alternative they would use it. *shrug* N1> until more recently probably due to compiler instructions I'll guess. Do you have any idea what those words mean? N1> te> This ham won't be running your code and will be advising others N1> te> not to do so. N1> N1> So you will cause defamation of my code? Under the grounds it does not N1> work I presume? While I'm quite happy you will not be running my N1> software, and while it's available from various distributions N1> repositories, under what grounds will you be advising people not to use N1> it? Oh no. Code is easy; I'm sure yours is fine. I won't use it because the author behaves poorly. N1> te> Well, obviously not. I've been asking for an explanation like that N1> te> you gave below for what, a week or two now? N1> N1> I've stated several times, the socket is left open. As you know an open N1> unused socket can easily be grabbed onto remotely by an attacker. "An unused socket" is just an unused data structure. There is nothing inherent about an "unused socket" that makes it so that it "can easily be grabbed onto remotely by an attacker." In THIS case, you may be right, but that is due to the specifics of this particular bug. It was the details particular to this specific issue that have been utterly lacking in your descriptions but that are critical to understanding, and thus addressing, this bug you've been going on about. Just being an "unused socket" can mean many things (for instance, it could be a slow resource leak, which is otherwise harmless though annoying). Getting the details of what precisely was/is wrong, and the effects of that bug, are what I've been driving at all this time. You seem to believe that that is somehow an affront to you, personally. Perhaps you should engage in some self-reflection to understand why you react so personally to a technical issue that you are only tangentially associated with. Could it be that you don't like being questioned because you consider yourself the prima facie expert on these matters? N1> N1> When a N1> N1> box boots up as fresh, and no users/robots have used the NetRom stack N1> N1> said box, it will await the 1st connection to which an underlaying ax N1> N1> VIRTUAL CIRCUIT is then created for the NetRom socket to transport N1> N1> through on. That 1st and only that 1st connection will appear to work N1> N1> and be valid. When the session is completed, the underlaying ax.25 la N1> N1> stays open thus causing the underlaying NetRom socket to be open and N1> N1> available for a remote attacker to attach to and own the box. N1> N1> te> Finally, something approaching a usable problem report! N1> N1> I've stated this several times. No you haven't. Objectively false statements like this, and your aversion to being corrected, are why I doubt you. N1> N1> Marius N1> N1> clearly spells this out in his patches and unlike a 1 line fix as you N1> N1> claim, it's a 4 line patch to insure that the ax.25 virtual circuit g N1> N1> closed when NetRom is used. N1> N1> te> Here's the patch: N1> N1> te> diff -r net/ax25/ax25_subr.c $HOME/ax25-4.19.0-16/ax25_subr.c N1> te> 290a291,295 N1> > else N1> > { N1> > // YO2LOJ: this is needed for proper NETROM connection cleanup o N1> timeout N1> > ax25_destroy_socket(ax25); N1> > } N1> N1> te> That's one line of executable code in an "else" branch. The other N1> te> three lines are brackets and a comment which is extremely generic. N1> N1> te> No where does any of this "explain" the things that you think it N1> te> does. N1> N1> It's perfectly clear to me that without the above, NetRom "cleanup" or N1> proper socket closure does not occur leaving it in an open state Er, no. It might just leak a data structure in the kernel. Nothing there implies that the socket is left "open"; just that the kernel data structure isn't cleaned up. N1> N1> Understand now? And if axip/axudp is used, N1> N1> this leaves the IP socket open awaiting any outside resource to conne N1> N1> to it. N1> N1> te> ...if you allow axip/axudp to the outside world. N1> N1> Have you seen most ham boxes? I'd safely say 95% of them do. You're not N1> far from me... the average age of a ham is 70. Most hams I know don't N1> even believe in passwords at all anywhere ham or internet usage! As I N1> said recently to one developer, it's more or less up to us to help N1> secure these guys in our code as best we can. While he disagreed with my N1> statement he did end up doing so. Non-sequitor. N1> te> So like I said, this is security through obscurity. Apparently, N1> te> a ham could set this up _today_ and have no idea this is such an N1> te> issue that could cost them their license. N1> N1> Possible, but not quite probable. It added to my decision to pull my N1> projects offline since my installer SVNs from SF.net. Many don't know N1> my stuff is in the linux repos... which is fine by me. Sometimes N1> obscurity is a better way to execute security. Maybe not in all cases N1> but under certain circumstances yes. Nonsense. Most hams installing a Raspberry Pi know little more than to try "apt install". You're already in rarified air when you talk about people setting up a packet station. "Sometimes obscurity is a better way to execute security." Except that this is neither obscure nor secure. N1> N1> This is simply one of many that need attention to. N1> N1> te> None of which are tracked. Awesome. N1> N1> not necessarily publically no... but tracked yes. Riiiight. --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64) * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101) .