Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd
On 17-2-2020 08:02, Borja Marcos wrote: On 14 Feb 2020, at 19:18, Ed Maste wrote: Upstream OpenSSH-portable removed libwrap support in version 6.7, released in October 2014. We've maintained a patch in our tree to restore it, but it causes friction on each OpenSSH update and may introduce security vulnerabilities not present upstream. It's (past) time to remove it. There’s no way to fight it? I know it’s an old program (first time I used it was back in 1992 or so!) but it’s really convenient and easy to use. I remember porting it to Apollo Domain OS with Wietse Venema when we both worked at Eindhoven University. And Wiestse was complaining that PID were not unique and sequential. So my guess would be that its origin lies somewhere around 1986-1988.. At that time TCPwrappers was a good part of security, since firewall and likes were close to hard to get and/or unavailable. But in current times there usually are better ways to fix things, but I guess that all use something of a firewall be it ipfw of pf. (using both sshguard, fail2ban or portsentry) So it'll be said to see it go, but I guess it has served its purpose. --WjW ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
OpenBSD Net-snmp Default File Permissions Let Local Users View SNMP Passwords
Hi, Dependant on whether we care for the snmp-passwords in our network. But: http://securitytracker.com/id/1034099 holds both for the /etc/snmpd.conf that is in base as well as for the net-snmp /usr/local/etc/snmpd/snmpd.conf version we have in ports. Most likely the ports version will be fixed when a new net-snmp release is issued, but the base version needs to be fixed in base. --WjW ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: OpenSSH HPN
On 10-11-2015 10:42, Dag-Erling Smørgrav wrote: Some of you may have noticed that OpenSSH in base is lagging far behind the upstream code. The main reason for this is the burden of maintaining the HPN patches. They are extensive, very intrusive, and touch parts of the OpenSSH code that change significantly in every release. Since they are not regularly updated, I have to choose between trying to resolve the conflicts myself (hoping I don't break anything) or waiting for them to catch up and then figuring out how to apply the new version. Therefore, I would like to remove the HPN patches from base and refer anyone who really needs them to the openssh-portable port, which has them as a default option. I would also like to remove the NONE cipher patch, which is also available in the port (off by default, just like in base). Hi Des, I know I've installed the ports once to see if, and how I would be able to add more IP-address infor to some of the warnings and errors. And then to get thos errors recognised by tools like sshguard and fail2ban. Only to find out that the code in that area in ports is completely different from what is in base. And submitting "patches" for that, even upstream, would be faily useless. So I understand the trouble you might have in getting other stuff in as well Getting the base version more inline with ports would be a real good thing. I guess you need to manage the fallout that there is going to be from those that expect HPN to be in base, and now suffer preformance issues. --WjW ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: OpenSSH HPN
On 10-11-2015 12:11, Dag-Erling Smørgrav wrote:
Willem Jan Withagen <w...@digiware.nl> writes:
Digging in my logfiles , and its things like:
sshd[84942]: Disconnecting: Too many authentication failures [preauth]
So errors/warnings without IP-nr.
And I think I fixed it on one server to also write:
error: maximum authentication attempts exceeded for root from
173.254.203.88 port 1042 ssh2 [preauth]
fail2ban should catch both of these since sshd will print a message for
each failed authentication attempt before it prints a message about
reaching the limit.
It's already too long to remember the full facts, but when I was looking
at the parser in sshguard, I think I noticed that certain accesses
weren't logged and added some more logging rules to catch those.
What I still have lingering is this snippet:
Index: crypto/openssh/packet.c
===
--- crypto/openssh/packet.c (revision 289060)
+++ crypto/openssh/packet.c (working copy)
@@ -1128,8 +1128,10 @@
logit("Connection closed by %.200s",
get_remote_ipaddr());
cleanup_exit(255);
}
- if (len < 0)
+ if (len < 0) {
+ logit("Read from socket failed: %.200s",
get_remote_ipaddr());
fatal("Read from socket failed: %.100s",
strerror(errno));
+ }
/* Append it to the buffer. */
packet_process_incoming(buf, len);
}
But like I said: The code I found at openssh was so totally different
that I did not continued this track, but chose to start running openssh
from ports. Which does not generate warnings I have questions about the
originating ip-nr.
Are they still willing to accept changes to the old version that is
currently in base?
No, why would they do that?
Exactly my question
I guess I misinterpreted your suggestion on upstreaming patches.
--WjW
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: OpenSSH HPN
On 10-11-2015 11:55, Dag-Erling Smørgrav wrote: > Willem Jan Withagen <w...@digiware.nl> writes: >> I know I've installed the ports once to see if, and how I would be >> able to add more IP-address infor to some of the warnings and >> errors. And then to get thos errors recognised by tools like sshguard >> and fail2ban. > > Do you mean logging IP addresses instead of hostnames? Just turn off > UseDNS. It is off by default since 6.8. No not really Digging in my logfiles , and its things like: sshd[84942]: Disconnecting: Too many authentication failures [preauth] So errors/warnings without IP-nr. And I think I fixed it on one server to also write: error: maximum authentication attempts exceeded for root from 173.254.203.88 port 1042 ssh2 [preauth] Which when I found out that upstreaming patches from base will be hard, because the whole logging in the ports version is totally different. > If you mean adding IP addresses or hostnames to messages that don't > already have them, try suggesting it on the openssh-portable mailing > list (openssh-unix-...@mindrot.org). Are they still willing to accept changes to the old version that is currently in base? --WjW ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: ftpd don't record login in utmpx
On 31-3-2015 05:44, Slawa Olhovchenkov wrote:
On Mon, Mar 30, 2015 at 08:08:49PM -0400, Lowell Gilbert wrote:
Slawa Olhovchenkov s...@zxy.spb.ru writes:
ftpd from FreeBSD-10 and up don't record ftp logins to utmpx database
(for case of chrooted login).
This is lack security information.
I found this is done by r202209 and r202604.
I can't understand reason of this.
Can somebody explain?
Having a jail log into the base system is a security issue in the
making. Can't you do this in a safer way by doing remote logging to the
base system rather than having the jail hold on to a file handle that
belongs outside the jail?
Jail? Why I you talk about jail?
It's certainly possible to maintain these kinds of capabilities, but
you would have to convince code reviewers that the same results can't be
achieved some other way that's easier to secure.
I might have just too many miles on the clock already
It used to liek this: to be able to do anything usefull in a chroot,
you'd rebuild those parts of the system tree that you need in under the
chrootdir.
Eg. including ls(1) and all the libs it needed to function in ftpd.
Some for apaches that ran chrooted, you'd carry/duplicate all you needed
into the chroot env
So in this case you probably need
${CHROOTDIR/var/log
and create the database there.
A Jail is no different in that, other than that it does this by default
in some of the packages: eg. ezjail.
--WjW
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: ftpd don't record login in utmpx
On 31-3-2015 10:44, Slawa Olhovchenkov wrote:
On Tue, Mar 31, 2015 at 10:09:00AM +0200, Willem Jan Withagen wrote:
On 31-3-2015 05:44, Slawa Olhovchenkov wrote:
On Mon, Mar 30, 2015 at 08:08:49PM -0400, Lowell Gilbert wrote:
Slawa Olhovchenkov s...@zxy.spb.ru writes:
ftpd from FreeBSD-10 and up don't record ftp logins to utmpx database
(for case of chrooted login).
This is lack security information.
I found this is done by r202209 and r202604.
I can't understand reason of this.
Can somebody explain?
Having a jail log into the base system is a security issue in the
making. Can't you do this in a safer way by doing remote logging to the
base system rather than having the jail hold on to a file handle that
belongs outside the jail?
Jail? Why I you talk about jail?
It's certainly possible to maintain these kinds of capabilities, but
you would have to convince code reviewers that the same results can't be
achieved some other way that's easier to secure.
I might have just too many miles on the clock already
It used to liek this: to be able to do anything usefull in a chroot,
you'd rebuild those parts of the system tree that you need in under the
chrootdir.
Eg. including ls(1) and all the libs it needed to function in ftpd.
Some for apaches that ran chrooted, you'd carry/duplicate all you needed
into the chroot env
So in this case you probably need
${CHROOTDIR/var/log
and create the database there.
I have many ftp acconts, than need be isolated by ftp.
I need united database about login and logout.
FreeBSD 1.x-9.x do this.
Why this removed in 10.x?
Slawa,
I can't tell you that, but it is in r202209. And you can ask the one
that removed it (ed@). :)
Like r202209 says 5 years ago:
Maybe we can address this in the future if it turns out to be a
real issue.
Hasn't been an issue uptill now, it seems.
But then there are many flavours of FTP server out there ATM, so freely
quoted from Andy Tannenbaum:
If you don't like this version, get another one.
Or write a script that actually unites the output from either the
database and/or last(8).
--WjW
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: ftpd don't record login in utmpx
On 31-3-2015 11:49, Slawa Olhovchenkov wrote:
On Tue, Mar 31, 2015 at 11:34:21AM +0200, Willem Jan Withagen wrote:
On 31-3-2015 10:44, Slawa Olhovchenkov wrote:
On Tue, Mar 31, 2015 at 10:09:00AM +0200, Willem Jan Withagen wrote:
On 31-3-2015 05:44, Slawa Olhovchenkov wrote:
On Mon, Mar 30, 2015 at 08:08:49PM -0400, Lowell Gilbert wrote:
Slawa Olhovchenkov s...@zxy.spb.ru writes:
ftpd from FreeBSD-10 and up don't record ftp logins to utmpx database
(for case of chrooted login).
This is lack security information.
I found this is done by r202209 and r202604.
I can't understand reason of this.
Can somebody explain?
Having a jail log into the base system is a security issue in the
making. Can't you do this in a safer way by doing remote logging to the
base system rather than having the jail hold on to a file handle that
belongs outside the jail?
Jail? Why I you talk about jail?
It's certainly possible to maintain these kinds of capabilities, but
you would have to convince code reviewers that the same results can't be
achieved some other way that's easier to secure.
I might have just too many miles on the clock already
It used to liek this: to be able to do anything usefull in a chroot,
you'd rebuild those parts of the system tree that you need in under the
chrootdir.
Eg. including ls(1) and all the libs it needed to function in ftpd.
Some for apaches that ran chrooted, you'd carry/duplicate all you needed
into the chroot env
So in this case you probably need
${CHROOTDIR/var/log
and create the database there.
I have many ftp acconts, than need be isolated by ftp.
I need united database about login and logout.
FreeBSD 1.x-9.x do this.
Why this removed in 10.x?
Slawa,
I can't tell you that, but it is in r202209. And you can ask the one
that removed it (ed@). :)
Like r202209 says 5 years ago:
Maybe we can address this in the future if it turns out to be a
real issue.
What about issue talk?
Opened file outside chroot? /dev/null and /var/run/logpriv still opened.
Disabling logging for chrooted accounts? Realy?!
Read the submit message!? The reason is there, nothing with security as
I read it, but it just did not fit into the way the new lib for wtmp
worked/works.
Clearly you do not agree, but you are rather late to the party.
Could be that in the mean time code has been added to wtmp, and now you
can do it from inside a chroot? Perhaps ask ed@ of on hackers@??
Hasn't been an issue uptill now, it seems.
But then there are many flavours of FTP server out there ATM, so freely
quoted from Andy Tannenbaum:
If you don't like this version, get another one.
Now I only see removing old and working functionality w/o reassonable
Well that is only in your eyes. wtmp moved (on) to a different way of
storing the data. At that point in time nobody had a problem with that.
And in 5 years you are the first one to be vocal about it.
Or write a script that actually unites the output from either the
database and/or last(8).
You kidding.
For this I need rearange ALL ftp acconts. Change permissions. Create
hieararhie. Learn users.
Well perhaps one of the other flavours of FTPDs suits your need better.
--WjW
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: ftpd don't record login in utmpx
On 31-3-2015 13:02, Slawa Olhovchenkov wrote: On Tue, Mar 31, 2015 at 12:28:04PM +0200, Willem Jan Withagen wrote: Slawa, I can't tell you that, but it is in r202209. And you can ask the one that removed it (ed@). :) Like r202209 says 5 years ago: Maybe we can address this in the future if it turns out to be a real issue. What about issue talk? Opened file outside chroot? /dev/null and /var/run/logpriv still opened. Disabling logging for chrooted accounts? Realy?! Read the submit message!? The reason is there, nothing with security as I read it, but it just did not fit into the way the new lib for wtmp worked/works. I read it. And I don't understund it. May be I don't know somewere. Or missed. Can you explain? In 9.0 the utmp stuff got rewritten, IIRC by Ed Schouten. But with the consequence that the API changed. And now it is no longer possible * to open a file at init, * keep it open while chrooting. * write records when needed. The interface is just completely different. Check: man utempter_add_record If you want the old behaviour, you have to dig into the code, and DIY. Clearly you do not agree, but you are rather late to the party. Could be that in the mean time code has been added to wtmp, and now you can do it from inside a chroot? Perhaps ask ed@ of on hackers@?? First I am ask security@. Logging login and logout -- security task. Not quite IMHO ... I'd consider security@ more of a thing where it involves things that are related to things that can cause a secirity problem. But then again I understand how you look at it. Hasn't been an issue uptill now, it seems. But then there are many flavours of FTP server out there ATM, so freely quoted from Andy Tannenbaum: If you don't like this version, get another one. Now I only see removing old and working functionality w/o reassonable Well that is only in your eyes. wtmp moved (on) to a different way of storing the data. At that point in time nobody had a problem with that. And in 5 years you are the first one to be vocal about it. All others still using old version? Or they don't care about the log. Or write a script that actually unites the output from either the database and/or last(8). You kidding. For this I need rearange ALL ftp acconts. Change permissions. Create hieararhie. Learn users. Well perhaps one of the other flavours of FTPDs suits your need better. I don't ask what I need do. I just ask why switch off logging. What issues may be happen? That is not the nice way to answer. I'm trying to explain why you have this problem. And as a mere suggestion I offered the insight that there are other FTPDs. Bluntly put: I don't think anybody is going to fix YOUR problem. If only because in 5 years time nobody had an issue with it. Regards, --WjW ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: DRAM Rowhammer exploits
On 09/03/2015 20:49, Dmitry Morozovsky wrote: Dear colleagues, any thoughts we're vulnerable to this? http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html As pointed out is this a hardware originated problem, not really fixable by software. Only EEC should be able to catch this. Which is mostly used on hardware for servers. And luckily that is probably also the most likely platforms on which unidentified third parties can run this. As no sensible PAAS/Hardware provider would forgo the use of ECC. :) I would expect this type of test to appear in tools like memtest86. Giving you in indication in advance of the the possible problem. Next to that I see a few points where we could possibly mitigate this. As I read the article, the problem is not present if the refresh frequency is doubled. This sort of indicates that manufacturers are (a bit) to optimistic about the required RAM refresh cycles. 1) If possible reprogram the RAM referesh cycle time as it is setup by the BIOS. It will reduce the available memory by an unmeasurable fraction. 2) It would be possible to build a RAM refresh thread in the kernel reading every RAM memory within a certain time frame. Thus forgoing the refresh recycle time set by the BIOS. This will require some cycles in the kernel, costing some CPU and some memory bandwidth. Big disadvantage could be that it will cause some serious thrashing of the cache content if these writes go thru the cache flowed by a cacheflush. --WjW ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: DRAM Rowhammer exploits
On 09/03/2015 22:37, Bakul Shah wrote: On Mon, 09 Mar 2015 20:46:19 - Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 20150309202308.64dfbb...@mail.bitblocks.com, Bakul Shah writes: On Mon, 09 Mar 2015 19:52:04 - Poul-Henning Kamp p...@phk.freebsd.dk wrote: Hopefully ECC memory protects against such exploits (at least makes them a lot less vulnerable). ECC only makes it harder, it doesn't make it impossible. According to the small sample in the paper below, the incidence of 3 bit errors is about 4000 times or more lower than single bit errors. These are the errors that may not even get detected by ECC. So not impossible but much better. ECC does not only correct bit errors, it also allows one the detect them. Perhaps a good reason to start watching the reports about them.. And how many bit do I need to change to actually do something usefull? It also proposes a few solutions. It seems to indicate that reducing refresh time by a factor of 7 (over 64ms) removes such errors. Hopefully this can be done via a firmware upgrade? That was my suggestion 1. Up the refresh frequency. Might require the manufacturer, but could very well be done by the kernel if it knew how,what,where to write this. I don't know if the physical page pool for kernel data can be isolated enough from user data to avoid this. [Probably not. Likely there is no standard way to do map a phys addr to a specific chip/row and diff. mfrs may use diff geometries. Though, perhaps this same phenomenon can be used to infer chip geometry!] Isn't this what the RAM chip info tells us? And RAM does not move around in the physical address space. So creating a mapping where virtual = physical (perhaps even offsetted into an empty block in the vast 2^64 bits address space) would allow the refresh tread to do its work. But creating that mapping while running in kernelmode could be not so easy. --WjW ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: Odd sshd entry in auth.log
On 2013-09-14 14:01, David Wolfskill wrote: Sep 13 12:43:24 albert sshd[43949]: fatal: Read from socket failed: Connection reset by peer [preauth] I see plentyu of these, if only because I test the sshd availablity with nagios without actually going thru the full login... I just abort once I see sshd report it's availability on the port. Hence the 'reset by peer [preauth].' Like DES says: Scanners generate more or less the same behavior. They scan, and try to determine if you are running a vulnerable sshd or something else they can work with I still have a wish on my todo to see if it is possible to report the ipnr... And then block hosts with to many tries. But it's not really high on the agenda... --WjW ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
On 2010-09-21 13:39, Andriy Gapon wrote: The Project is ultimately about the users, right? There are early signs that some old FreeBSD users get tired from those changes, those removals, lesser POLA adherence, marketing-not-technical-stuff for time-not-feature-based releases, not so stable -STABLE as it used to be, and so on, migrating to other systems. And older users are more valuable to project than newer ones. May be it's time to revert to some of thet Old Good Things, if decade-long project is mostly ended, while those signs are still early and not a strong tendency?.. Given this thread, I've mentioned earlier about 12 messages in announce@ from 2002 with such public calls for volunteers - there are several years already without these. Well, let me pitch in here a bit, because this discussion has had me on the edge of commenting already for too long. I'm a FreeBSD user as early as 1993, still have the first 1.0 CD here as nice remembrance. So I guess that I qualify as one of those old FreeBSD users. And I completely disagree with you. If you have been such an old freebsd user,then you should know the immense effort there has been to move GIANT out of the way. I cann't even get close to describing what a huge respect I have for the people that dared to undertake such a humongous effort. With an high probability of being flamed to death... But still ever since 5.x I've seen things really improve for the better. And yes, I was sorry to see ISDN being removed, but as things have progressed another version has been returned instead. And sure I have more hardware than you can imagine that is no longer supported. But it is all old, and worn down, sometimes it is even still VESA stuff. And right,there have been variations in the level of what you would like to call stable. But compared to the old days I would say, it has always been above my expectation. And note that I have and still do run 24*7 business on this. FreeBSD has never NEVER ever let me down. So as far as I'm concerned you are barking up the wrong tree here. --WjW ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
On 2010-09-21 15:16, Jeremy Chadwick wrote:
On Tue, Sep 21, 2010 at 02:59:46PM +0200, Willem Jan Withagen wrote:
On 2010-09-21 13:39, {some mysterious person :-)} wrote:
The Project is ultimately about the users, right? There are early signs that
some old FreeBSD users get tired from those changes, those removals, lesser
POLA adherence, marketing-not-technical-stuff for time-not-feature-based
releases, not so stable -STABLE as it used to be, and so on, migrating to
other systems. And older users are more valuable to project than newer ones.
May be it's time to revert to some of thet Old Good Things, if decade-long
project is mostly ended, while those signs are still early and not a strong
tendency?.. Given this thread, I've mentioned earlier about 12 messages in
announce@ from 2002 with such public calls for volunteers - there are several
years already without these.
Andriy wasn't the one who wrote this. In fact, I'm not sure who the
quote actually came from because I never received the Email it came
from, but I'm under the impression it's from Vadim. My mail spool:
My bad for not checking the included reference.
I was also very much under the impression that that quote was Vadim's,
since it was in completeline with his previous complaints/rants/whining.
And yes, your are smart to stay out of the discussion. But this old fart
just had too much urge to react. So now I'll just go back to my old
lurking state.
--WjW
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: denyhosts-like app for MySQLd?
Jordi Espasa Clofent wrote: Hi, There is a functionality in pf, that allows you to have an application to update a list of hosts, that is used in a rule. You could have a script harvest the addresses from your log files, and then update the table in pf. I have not tried it myself, but was looking at adopting an implementation to create a tarpit for spammers based on this idea. Yes Tim, I know it. The problem is the servers are builded in IPFW as firewall solution. I've tried the limit IPFW's option... but isn't exactly what I'm looking for. Have a look at swatch in the ports, and build some rules that add blocking rules to the beginning of your firewall rule set. I've got servers running with 3500 rules ;), and the box doesn't even notices it. (you can even/easily do things in perl embedded in the rules.) The best suggestion is of course to only let those in, you want to let in. Block others by default. I'm using the above scenario on public mailservers, with harvesting from the postgrey output. And from the ssh log output. --WjW ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
