Subj : Re: Tutorial for rookies To : tenser From : N1uro Date : Wed Oct 13 2021 12:07 am tenser; -=> tenser wrote to N1uro <=- te> On 12 Oct 2021 at 01:25p, N1uro pondered and said... te> If I ask for some data, and you cannot provide it, then yes, te> I question your veracity. In particular, if this code is being te> maintained and the issue in question isn't being effectively te> tracked, how do you know it hasn't already been fixed? How do te> you know that the people doing the maintenance are even aware? You've asked for data and I've done what I could and beyond to provide it. I know who's maintaining the code in question as we email amongst ourselves. We all share code. I know some code has been fixed, some yet has been fixed. I'm hoping by year end it'll all be fixed. te> I merely asked you for a pointer to a bug repository where these te> issues were being tracked. That's not "hateful". You refused te> to provide any details. Repeated refusals make me wonder if it's te> really a problem. I have not refused answers. Specific details perhaps because of the fact that it's not a good idea to let non-hams have information on how to exploit ham boxes. You want these published however to which I can not understand for the life of me why. I did point you to a more current archive of linux-hams which you claimed did not exist. te> You might consider showing some appreciation for people who are te> interested in these things; who knows, they may be able to fix te> some bugs. If you emailed me privately we could get into more details. In a public echo area is not the place to discuss these things. I do appreciate those who use such things, often it's me that gets the disrepect and frankly I grow tired of it. te> Sounds like security through obscurity to me. Think of this way: te> what's to prevent a ham from doing this _right now_, since these te> problems are, as you claim, unsolved upstream. How would that ham te> _even know_? By your own admission, this isn't even being tracked te> anywhere. How would they possibly discover the issue? Publically it's not tracked. Privately yes. Many ham projects are tracked securely via obscurity. Why would I have a reason to say that sockets are left open if it's not true? In what way(s) would I gain any benefit either way? Zero! te> Your own statements that the project is not available on te> sourceforge because of these kernel issues you continue to te> talk about. Those who have used my software for the 20+ years it's been around know me and know I would help them out. I don't want any new users at this time but will help those who do grab it using apt or dnf to install them with. 95% however when faced with having to compile a kernel or patch a kernel usually will flee back to DOS. I am also in very poor health and don't wish to be bothered by those who aren't willing to take the steps needed. Those who do use my software will wait quite patiently for the projects to be reposted with the upgrades in them. I'm not concerned. te> https://github.com/dancrossnyc/ Ahh now I know who you are. I assigned you your block and maintain your ampr DNS. Considering the level of integrity I gave you to get you up and running on 44-net, what reason did I offer you to prove not to believe me? Again, I have nothing to gain either way here. N1> Besides my own projects I also N1> contribute to the LinFBB project. te> That's nice...? You could always also look inside the tickets of LinFBB on the afore mentioned issues. F6BVP and his crew supplied ROSE patches as the URONode crew has supplied NetRom fixes. Others have supplied various fixes to various codes. Some have to do with the ax25 libs some with the kernel protocol stack. The ones I personally am most concerned about are the 6-pack and NetRom bugs. N1> I pulled my projects off sourceforge N1> until such time as the kernel bugs are fixed. I'm simply tired with N1> receiving emails asking me why my stuff "doesn't work" when I have the N1> only node project available that works on old IBM emulation systems! te> This seems to directly contradict your statement above that your te> didn't pull your projects off of sourceforge. I -said- I pulled them off, however various distros still have the software in their repositories. te> Cool. What guarantee do we have that you won't yank them again? te> Once you establish a pattern of behavior, users and potential te> users will recognize it for what it is and react accordingly. I have announced that once the issues are fixed they'll be back. My core base knows that I'll hold true to my word. Hopefully the stack issues once fixed will remain fixed TFN. It seems as if some of these bugs have been in existence since the 1990s however just weren't noticed until more recently probably due to compiler instructions I'll guess. te> This ham won't be running your code and will be advising others te> not to do so. So you will cause defamation of my code? Under the grounds it does not work I presume? While I'm quite happy you will not be running my software, and while it's available from various distributions repositories, under what grounds will you be advising people not to use it? te> Well, obviously not. I've been asking for an explanation like that te> you gave below for what, a week or two now? I've stated several times, the socket is left open. As you know an open unused socket can easily be grabbed onto remotely by an attacker. N1> When a N1> box boots up as fresh, and no users/robots have used the NetRom stack in N1> said box, it will await the 1st connection to which an underlaying ax.25 N1> VIRTUAL CIRCUIT is then created for the NetRom socket to transport N1> through on. That 1st and only that 1st connection will appear to work N1> and be valid. When the session is completed, the underlaying ax.25 layer N1> stays open thus causing the underlaying NetRom socket to be open and N1> available for a remote attacker to attach to and own the box. te> Finally, something approaching a usable problem report! I've stated this several times. N1> Marius N1> clearly spells this out in his patches and unlike a 1 line fix as you N1> claim, it's a 4 line patch to insure that the ax.25 virtual circuit gets N1> closed when NetRom is used. te> Here's the patch: te> diff -r net/ax25/ax25_subr.c $HOME/ax25-4.19.0-16/ax25_subr.c te> 290a291,295 > else > { > // YO2LOJ: this is needed for proper NETROM connection cleanup on timeout > ax25_destroy_socket(ax25); > } te> That's one line of executable code in an "else" branch. The other te> three lines are brackets and a comment which is extremely generic. te> No where does any of this "explain" the things that you think it te> does. It's perfectly clear to me that without the above, NetRom "cleanup" or proper socket closure does not occur leaving it in an open state N1> Understand now? And if axip/axudp is used, N1> this leaves the IP socket open awaiting any outside resource to connect N1> to it. te> ...if you allow axip/axudp to the outside world. Have you seen most ham boxes? I'd safely say 95% of them do. You're not far from me... the average age of a ham is 70. Most hams I know don't even believe in passwords at all anywhere ham or internet usage! As I said recently to one developer, it's more or less up to us to help secure these guys in our code as best we can. While he disagreed with my statement he did end up doing so. te> So like I said, this is security through obscurity. Apparently, te> a ham could set this up _today_ and have no idea this is such an te> issue that could cost them their license. Possible, but not quite probable. It added to my decision to pull my projects offline since my installer SVNs from SF.net. Many don't know my stuff is in the linux repos... which is fine by me. Sometimes obscurity is a better way to execute security. Maybe not in all cases but under certain circumstances yes. N1> This is simply one of many that need attention to. te> None of which are tracked. Awesome. not necessarily publically no... but tracked yes. --- MultiMail/Linux v0.52 * Origin: Carnage - risen from the dead now on SBBS (21:4/107) .