Re: Possible break-in attempt?

[Jason Hellenthal]

See etc/periodic/... security related scripts. Should get you on a good start.

-- 

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Jul 18, 2018, at 16:47, Grzegorz Junka  wrote:
> 
> 
> Thank you Patrick, Simon and Dimitry for a quick follow up and the 
> explanation.
> 
> Is it possible to figure out which parts of the security run output emails 
> are produced by which tools (I assume that each part is a separate check)? 
> Could be useful to know when checking other messages in that email. Is there 
> some kind of email template or script that generates these emails?
> GrzegorzJ
> ___
> 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"
___
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: http subversion URLs should be discontinued in favor of https URLs

[Jason Hellenthal]

The truly paranoid types that don’t want anyone to know they are using FreeBSD 
apparently.

Honestly if they are that worried about http then get a private vpn tunnel and 
run through that instead !

> On Dec 7, 2017, at 16:27, Poul-Henning Kamp  wrote:
> 
> 
> In message <2a6d123c-8ee5-8e1e-d99b-4bce02345...@rawbw.com>, Yuri writes:
> 
>> The unfortunate FreeBSD user who updated his source tree through 
>> Tor [...]
> 
> Why would anybody do that in the first place ?
> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> 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"
> 
___
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: bash velnerability

[Jason Hellenthal]

echo Testing Exploit 1 (CVE-2014-6271)
CVE6271=$(env x='() { :;}; echo -n V' bash -c : 2/dev/null)
[ ${CVE7187} == V ]  echo VULNERABLE || echo NOT VULNERABLE

echo Testing Exploit 2 (CVE-2014-7169)
CVE7169=$(env X='() { (4lpi.com)=\' bash -c echo date 2/dev/null; cat echo 
2/dev/null; rm -f echo)
[ ! ${CVE7169} == date ]  echo VULNERABLE || echo NOT VULNERABLE

echo Testing Exploit 3 (CVE-2014-6277)
CVE6277=$(env -i X=' () { }; echo -n V' bash -c :)
[ ${CVE6277} == V ]  echo VULNERABLE || echo NOT VULNERABLE

echo Testing Exploit 4 (CVE-2014-7186)
CVE7186=$(bash -c 'true EOF EOF EOF EOF EOF EOF EOF EOF EOF 
EOF EOF EOF EOF EOF' 2/dev/null ||echo -n V)
[ ${CVE7186} == V ]  echo VULNERABLE || echo NOT VULNERABLE

echo Testing Exploit 5 (CVE-2014-7187)
CVE7187=$((for x in {1..200}; do echo for x$x in ; do :; done; for x in 
{1..200}; do echo done; done) |bash 2/dev/null ||echo -n V)
[ ${CVE7187} == V ]  echo VULNERABLE || echo NOT VULNERABLE”

Good luck ;-)

On Sep 30, 2014, at 13:54, Jung-uk Kim j...@freebsd.org wrote:

 On 2014-09-29 12:13:15 -0400, Bryan Drewery wrote:
 On 9/29/2014 11:01 AM, Mike Tancsa wrote:
 On 9/26/2014 5:01 PM, Bryan Drewery wrote:
 On 9/26/2014 12:41 PM, Bryan Drewery wrote:
 On 9/26/2014 11:51 AM, Bryan Drewery wrote:
 On 9/26/2014 11:46 AM, Bartek Rutkowski wrote:
 Apparently, the full fix is still not delivered, accordingly to this:
 http://seclists.org/oss-sec/2014/q3/741
 
 Kind regards,
 Bartek Rutkowski
 
 
 I'm pretty sure they call that a feature. This is a bit different.
 
 I've disabled environment function importing in the port. Using
 --import-functions will allow it to work if you need it.
 
 Hi Bryan,
With the latest ports, bashcheck still sees some issues with bash.
 Are these false positives on FreeBSD ?
 
 Using
 https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck
 
 Not vulnerable to CVE-2014-6271 (original shellshock)
 Not vulnerable to CVE-2014-7169 (taviso bug)
 ./bashcheck: line 18: 54908 Segmentation fault  (core dumped) bash
 -c true $(printf 'EOF %.0s' {1..79}) 2 /dev/null
 Vulnerable to CVE-2014-7186 (redir_stack bug)
 Test for CVE-2014-7187 not reliable without address sanitizer
 Variable function parser inactive, likely safe from unknown parser bugs
 
---Mike
 
 Yes we have not applied the RedHat fix for CVE-2014-7186 or CVE-2014-7187.
 
 Applying the first patch for parse.y from the following post passed the
 tests for me.
 
 http://www.openwall.com/lists/oss-security/2014/09/25/32
 
 In fact, all major Linux distros seem to use it now.
 
 FYI,
 
 Jung-uk Kim
 ___
 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

-- 
 Jason Hellenthal
 Mobile: +1 (616) 953-0176
 jhellent...@dataix.net
 JJH48-ARIN

___
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: bash velnerability

[Jason Hellenthal]

I would agree with that. Considering the korn shell was found out to be 
importing functions from bash this morning that it does not completely know how 
to interpret goes to say that there is a much bigger issue at face here than 
the mere sys admins can begin to fathom quite yet.

There is still more to come from this. We may not see the end of it for the 
next 10 years.

But also to state bash 4.3.27 on 10-RELEASE-p9 reports as not vulnerable to the 
five known CVEs right now but that same shell compiled on a 9.1-RELEASE system 
is still vulnerable to the last two CVEs … That said this is deep just when you 
think you have it conquered.

On Sep 30, 2014, at 16:25, Charles Swiger cswi...@mac.com wrote:

 On Sep 30, 2014, at 12:46 PM, Bryan Drewery bdrew...@freebsd.org wrote:
 [ ... ]
 I even saw a reddit post last night complaining that OSX had updated
 bash only to leave it still vulnerable because of the redir_stack issue.
 
 It doesn't seem to be?
 
 bash-3.2$ bash --version
 GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13)
 Copyright (C) 2007 Free Software Foundation, Inc.
 
 bash-3.2$ echo Testing Exploit 4 (CVE-2014-7186)
 Testing Exploit 4 (CVE-2014-7186)
 bash-3.2$ CVE7186=$(bash -c 'true EOF EOF EOF EOF EOF EOF EOF 
 EOF EOF EOF EOF EOF EOF EOF' 2/dev/null ||echo -n V)
 bash-3.2$ [ ${CVE7186} == V ]  echo VULNERABLE || echo NOT 
 VULNERABLE
 NOT VULNERABLE
 
 This being said, I'm not confident that there won't be further issues found 
 with bash
 
 Regards,
 -- 
 -Chuck
 
 ___
 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

-- 
 Jason Hellenthal
 Mobile: +1 (616) 953-0176
 jhellent...@dataix.net
 JJH48-ARIN

___
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: NEVERMIND! (was: Local Denial of Service: logger(1))

[Jason Hellenthal]

That and/or you could just disallow the use of logger to that of just a special 
group say staff and modify the mtree(8) files to keep the changes. 

These are just medial tasks into hardening a system for its specific needs. 
security/logcheck should pick up these events pretty quickly and shoot out an 
email to your admin group to alert them of the miscreant :-)

-- 
 Jason Hellenthal
 Voice: 95.30.17.6/616
 JJH48-ARIN

 On May 25, 2014, at 23:37, Ronald F. Guilmette r...@tristatelogic.com 
 wrote:
 
 
 In message 2091.1401074...@server1.tristatelogic.com, I wrote:
 
 ==
 #!/bin/sh
 
 while (1)
   dd if=/dev/random bs=15 count=1 | od -c | xargs logger
 end
 ==
 
 DUH!
 
 I forgot that newsyslog(8) should limit the size of /var/log/messages, and
 that as long as you limit the size of that to a reasnable value, and as
 long as you have newsyslog(8) only keeping a finite  reasonable number
 of rotated out copies, then /var won't fill up.
 
 My apologies to everyone for the distraction.
 ___
 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


smime.p7s
Description: S/MIME cryptographic signature

Re: am I NOT hacked?

[Jason Hellenthal]

Excuse me but there is nothing about the information you have provided that 
could or would suggest that you have or have not been hacked. There is not a 
way from the very little information that you have provided to diagnose that 
and doesn't seem that you have covered all the avenues possible to even detect 
an unwanted change in your systems.

For the least part yes FreeBSD does store the passwd info in a database. You 
could have skipped running vipw(8) and just run pw_mkdb /etc/master.passwd to 
resolve that problem. Its common knowledge.

To solve the hacked or not hacked problem you should take the steps to create a 
new clean system and migrate your data but j doubt this list is a justified 
medium to discuss all the possible avenues that you would have to cover on a 
possibly compromised system.

Clean fresh system and start from there.

Good luck 

-- 
 Jason Hellenthal
 Voice: 95.30.17.6/616
 JJH48-ARIN

 On Apr 26, 2014, at 5:55, Joe Parsons jp4...@outlook.com wrote:
 
 I was slow to patch my multiple vms after that heartbleed disclosure.  I just 
 managed to upgrade these systems to 9.2, and installed the patched openssl, 
 then started changing passwords for root and other shell users.  However I 
 realized that, only the root password was changed.  For other users, even 
 though the passwd userid issued no warning, and echo $? is 0, the 
 password is NOT changed.
 
 For more debugging, I tried to adduser, the command was successful, and I 
 can see the new entry test in /etc/passwd. However finger test complains 
 no such user!  Also, rm test complains there is no such user to delete as 
 well.
 
 Furthermore, the mail server got problem sending email, the log file said 
 there is no such user postfix, and sure enough:
 
 # finger postfix
 finger: postfix: no such user
 
 while this postfix user certainly existed for years, and I can see see its 
 entry in /etc/passwd.
 
 This appeared to all the multiple vms on multiple hosts, all running FreeBSD 
 9.2 now.
 
 I was paranoid, I really should have patched all these systems immediately 
 reading that heartbleed news, as all these servers had the vulnerable openssl 
 port installed!
 
 Until googling and I found this: 
 
 https://forums.freebsd.org/viewtopic.php?t=29644
 
 it said The user accounts are actually stored in a database. It's possible 
 it got out of sync with your [file]/etc/passwd[/file] file., and it 
 suggested running vipw to fix it.
 
 I ran vipw, then saved, and quit.  No joy.  Then ran vipw again, made a 
 change, then undid the change, save again.  Now finger postfix found the 
 user, and I can change user password now, and all the above problem 
 disappeared.
 
 Am I right that, that I am NOT hacked?  Is the above problem produced by the 
 freebsd-update process?  Is this supposed to happen?  I just followed the 
 handbook to update from 9.1-RELEASE to 9.2-RELEASE, never compiled kernel or 
 tweak.
 
 Thank you!  Joe
 
 ___
 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


smime.p7s
Description: S/MIME cryptographic signature

Re: freebsd openssh hole?

[Jason Hellenthal]

What is so confusing about this ?

I don't see anything here that would cause worry besides the zealot attitudes 
you would typically find in the openbsd community. For them to be so security 
conscious and open source but yet not have the decency or common sense to 
mitigate major security concerns among other open source projects leaves quite 
the distasteful essence on my tongue to use any of their software in any 
corporate environment whatsoever. Guess maturity comes in just as many flavors 
as Linux these days.

-- 
 Jason Hellenthal
 Voice: 95.30.17.6/616
 JJH48-ARIN

 On Apr 11, 2014, at 4:38, Nicolas Rachinsky 
 fbsd-securit...@ml.turing-complete.org wrote:
 
 Hallo,
 
 http://thread.gmane.org/gmane.os.openbsd.tech/35722/focus=35731
 confuses me a bit.
 
 Should this be taken serious?
 
 Nicolas
 ___
 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


smime.p7s
Description: S/MIME cryptographic signature

Login failures usefulness with OpenSSH 6.1

[Jason Hellenthal]

Hello everyone,

It seems that the login failures reported by the security output of a nightly 
periodic job has become somewhat useless per OpenSSH 6.1.

I used to get username and IP address in the output but it seems that the 
logging format has changed. Instead of one line the log format now has two 
lines. One like the ones below and then another coinciding line that contains 
IP address and username.

I think it would be more beneficial outputting the lines with the ip and 
username over the ones below for the security output.

Not sure exactly when this changed but would like to gather some input before I 
inspect further on the changes that would have to be made.

My output is from SVN FreeBSD STABLE 8.3 as of yesterday.


Thanks  Clean Regards,

...Sample output...

login failures:
May  4 00:04:35 disbatch sshd[48898]: fatal: Write failed: Operation not 
permitted
May  4 14:54:14 disbatch sshd[9544]: input_userauth_request: invalid user root 
[preauth]
May  4 18:44:04 disbatch sshd[18326]: fatal: Read from socket failed: 
Connection reset by peer [preauth]

-- 
 Jason Hellenthal
 JJH48-ARIN
 -(2^(N-1))

___
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: FreeBSD Security Advisory FreeBSD-SA-13:02.libc

[Jason Hellenthal]

No running daemons with listening ports effected that could trigger it?

-- 
 Jason Hellenthal
 JJH48-ARIN
 - (2^(N-1))


On Feb 19, 2013, at 10:48, Philip M. Gollucci pgollu...@p6m7g8.com wrote:

 This is an internal only vuln with local user account.  I see no need to
 rush this one.  We'll pick it up at a later date.
 
 
 On Tue, Feb 19, 2013 at 9:04 AM, FreeBSD Security Advisories 
 security-advisor...@freebsd.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 =
 FreeBSD-SA-13:02.libc   Security
 Advisory
  The FreeBSD
 Project
 
 Topic:  glob(3) related resource exhaustion
 
 Category:   core
 Module: libc
 Announced:  2013-02-19
 Affects:All supported versions of FreeBSD.
 Corrected:  2013-02-05 09:53:32 UTC (stable/7, 7.4-STABLE)
2013-02-19 13:27:20 UTC (releng/7.4, 7.4-RELEASE-p12)
2013-02-05 09:53:32 UTC (stable/8, 8.3-STABLE)
2013-02-19 13:27:20 UTC (releng/8.3, 8.3-RELEASE-p6)
2013-02-05 09:53:32 UTC (stable/9, 9.1-STABLE)
2013-02-19 13:27:20 UTC (releng/9.0, 9.0-RELEASE-p6)
2013-02-19 13:27:20 UTC (releng/9.1, 9.1-RELEASE-p1)
 CVE Name:   CVE-2010-2632
 
 For general information regarding FreeBSD Security Advisories,
 including descriptions of the fields above, security branches, and the
 following sections, please visit URL:http://security.FreeBSD.org/.
 
 I.   Background
 
 The glob(3) function is a pathname generator that implements the rules for
 file name pattern matching used by the shell.
 
 II.  Problem Description
 
 GLOB_LIMIT is supposed to limit the number of paths to prevent against
 memory or CPU attacks.  The implementation however is insufficient.
 
 III. Impact
 
 An attacker that is able to exploit this vulnerability could cause
 excessive
 memory or CPU usage, resulting in a Denial of Service.  A common target for
 a remote attacker could be ftpd(8).
 
 IV.  Workaround
 
 No workaround is available.
 
 V.   Solution
 
 Perform one of the following:
 
 1) Upgrade your vulnerable system to a supported FreeBSD stable or
 release / security branch (releng) dated after the correction date.
 
 2) To update your vulnerable system via a source code patch:
 
 The following patches have been verified to apply to the applicable
 FreeBSD release branches.
 
 a) Download the relevant patch from the location below, and verify the
 detached PGP signature using your PGP utility.
 
 # fetch http://security.FreeBSD.org/patches/SA-13:02/libc.patch
 # fetch http://security.FreeBSD.org/patches/SA-13:02/libc.patch.asc
 # gpg --verify libc.patch.asc
 
 b) Execute the following commands as root:
 
 # cd /usr/src
 # patch  /path/to/patch
 
 Recompile the operating system using buildworld and installworld as
 described in URL:http://www.FreeBSD.org/handbook/makeworld.html.
 
 Restart all daemons, or reboot the system.
 
 3) To update your vulnerable system via a binary patch:
 
 Systems running a RELEASE version of FreeBSD on the i386 or amd64
 platforms can be updated via the freebsd-update(8) utility:
 
 # freebsd-update fetch
 # freebsd-update install
 
 Restart all daemons, or reboot the system.
 
 VI.  Correction details
 
 The following list contains the revision numbers of each file that was
 corrected in FreeBSD.
 
 Branch/path  Revision
 - -
 stable/7/ r246357
 releng/7.4/   r246989
 stable/8/ r246357
 releng/8.3/   r246989
 stable/9/ r246357
 releng/9.0/   r246989
 releng/9.1/   r246989
 - -
 
 VII. References
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2632
 
 The latest revision of this advisory is available at
 http://security.FreeBSD.org/advisories/FreeBSD-SA-13:02.libc.asc
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (FreeBSD)
 
 iEYEARECAAYFAlEjf80ACgkQFdaIBMps37JFUgCfUrw8Ky4U19COja6fna49Calv
 z/YAn1JSGxzHCo8vLj4XhtXqrQt68or4
 =mCPv
 -END PGP SIGNATURE-
 ___
 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: getting the running patch level

[Jason Hellenthal]

On Sat, Aug 11, 2012 at 09:05:44PM +0200, Dag-Erling Smørgrav wrote:
 Simon L. B. Nielsen si...@freebsd.org writes:
  This has been discussed a number of time, but there are no nice and
  simple solution.
 
 There is a simple solution that, while not bulletproof, would work well
 enough in most cases: have 'make installworld' create /etc/issue, which
 would look like this:
 
   FreeBSD 9.0-RELEASE-p4 amd64/amd64
 

Could I suggest... the same way that /etc/motd is already updated ?

-- 

 - (2^(N-1)) JJH48-ARIN

___
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: Pull in upstream before 9.1 code freeze?

[Jason Hellenthal]

On Wed, Jul 04, 2012 at 10:01:04AM -0700, Freddie Cash wrote:
 On Wed, Jul 4, 2012 at 9:51 AM, Simon L. B. Nielsen si...@freebsd.org wrote:
  On Tue, Jul 3, 2012 at 9:39 PM, Doug Barton do...@freebsd.org wrote:
  On 07/03/2012 05:39, Dag-Erling Smørgrav wrote:
  Doug Barton do...@freebsd.org writes:
  The correct solution to this problem is to remove BIND from the base
  altogether, but I have no energy for all the whinging that would happen
  if I tried (again) to do that.
 
  I don't think there will be as much whinging as you expect.  Times have
  changed.
 
  I'm willing to import and maintain unbound (BSD-licensed validating,
  recursive, and caching DNS resolver) if you remove BIND.
 
  You've got a deal!
 
  Unbound requires ldns, which is a good thing. Part of this project would
 
  How's the security support for ldns / unbound? For third party
  software sitting in the 'frontline' that part is rather important.
 
  also be to enable drill so that we have a command-line dns lookup tool
  in the base, but that's trivial once you've got ldns imported.
 
  Does that means loosing host(1) ? That would be somewhat annoying.
 
 There's a version of host based on unbound.  At least, there's an
 unbound-host package for Debian Linux:
 
 http://packages.debian.org/search?keywords=unbound-host
 

What would be really nice here is a command wrapper hooked into the
shell so that when you type a command and it does not exist it presents
you with a question for suggestions to install somewhat like Fedora has
done.

You type nmap in the root shell and it will ask you if you would like to
install it.

With that said, given this is FreeBSD, it could offer ...

Would you like to install base package [y/N] ?: N
Would you like to install ports package [y/N] ?: N
Would you like to compile this from ports [y/N] ?: Y

You have these options available:
1) BIND
2) LDNS
3) DJBDNS

Which would you like [0-3]: 


I entirely dislike the idea of including something other than bind-tools
within base that are installed, but fully support the idea of providing
a way to allow the user to install a base package one that is meant to
install into the base system and have as many as are seen suited to
support the community.

I currently buildworld WITHOUT_BIND and use bind from ports and cannot
justify the time to go through learning/using another instance or at
least at this time when BIND has been perfect for everything I needed to
do.

-- 

 - (2^(N-1))
___
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: BSD TelnetD Exploit on one of my servers

[Jason Hellenthal]

How about some sort of indication of what you are running...

uname -a ?

On Wed, Jun 27, 2012 at 12:17:01AM +0200, trap9 trap9 wrote:
 This is what I find on one of my servers :
 It appears to be a telnet exploit code for CVE-2011-4862.
 
 http://www.4shared.com/zip/mgSStKnU/wolverine-final.html
 
 Richard
 ___
 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

-- 

 - (2^(N-1))
___
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: / owned by bin causes sshd to complain bad ownership

[Jason Hellenthal]

On Fri, Jun 22, 2012 at 03:43:47PM +0200, Julian H. Stacey wrote:
 Hi freebsd-security@freebsd.org
 On an 8.3-RELEASE running sshd, /var/log/auth.log 
   Jun 22 12:54:06 lapr sshd[57505]: Authentication refused:
   bad ownership or modes for directory /
 Until I did
   chown 0:0 /
 ( It was previously
   drwxr-xr-x  25 bin   bin   1024 Jun 20 19:53 ./
 )
 The chown is consistent with all of 8.3 /bin also being root  not bin,
 
 BUT
 
 Over use of Root seems Bad. 
 Our ownership scheme has degraded compared to early 1980s Unix, where
   most bin  lib files  dirs were owned by bin, except for
   - a few SUID bins that Needed root
   - occasional administrator droppings,
 temporary accidental files that glared at the eyeball,
 as root, cos near all else was just bin.
 
 IMO very little in a system should be user root.
 
 Apologies, but to guide replies :
   (after threads burnt by a troll on another list)
   I'd not appreciate replies just along the lines of
It has to be to satisfy existing software. 
   I'd much rather receive replies along lines of 
   What would be best ownership scheme, advantages 
disadvantages + should we change anything ?
 

What are you currently using this in that is the cause of the problem ?

Is this a jail, physical system, VM ...

It is not really clear why you would want to change the permissions of
root:wheel of / on any of these. root is the owner of the system ... it
is pretty much a standard if not already that root owns everything so I
am not really following why.

openssh in itself... I am glad it does this. If a system has been
compromised by changing owner:group of / then it denies access to the
whole system. This is a security benefit.

Security principles are well laid out and have not changed in a long
time. Vering away from those principles will cause a LOT of
administrative overhead as most software out there can expect a sane
environment if / is root:wheel


-- 

 - (2^(N-1))
___
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: (Free 7.2) su -l didnt prompt password.Is it possbile?

[Jason Hellenthal]

On Mon, Jun 18, 2012 at 05:31:54PM +0400, Budnev Vladimir wrote:
 Hello everyone.
 We'v noticed some strange situation. After reboot and login, system 
 didn't ask for password while switchig with su -l.
 
 In details, there was root login from terminal and one from ssh.
 Terminal login was directly as root(via ip-console), and ssh was as 
 user, then attemped switch to root with su -l, and there were NO 
 password request,no prompt at all. At the same time login from terminal 
 accepted root password, first I thought that means password wasn't 
 empty, but system even with empty password should print Password:..and 
 that time it was nothing absolultey. We even logged out and then su -l 
 again.
 
 And It looked such way:
 
 %su -l
 St-serv#
 St-serv# exit
 %su -l
 St-serv#
 
 We'v been shocked and hurried a bit and changed root password without 
 /etc/master.passwd backup for explorations.
 After chagning password we cant no reprocude such behaviour.
 
 It's also should be noticed that system was booting after unsafe power 
 shutdown, and there was fs-check running in background(accroding to 
 logs), corrected cleared some files(searching by inum resulted to nothing).
 
 sysctl -a gave such string:
 118Starting background file system checks in 60 seconds.
 118
 
 and in /var/log/messages we could see:
 Jun 15 14:57:39 St-serv kernel: em0: link state changed to UP
 Jun 15 14:57:49 St-serv login: ROOT LOGIN (root) ON ttyv0
 Jun 15 14:58:47 St-serv fsck: /dev/ad0s1e: 71 files, 11 used, 2538508 
 free (84 frags, 317303 blocks, 0.0% fragmentation)
 Jun 15 15:02:31 St-serv fsck: /dev/ad0s1f: 264646 files, 1378041 used, 
 60368113 free (43545 frags, 7540571 blocks, 0.1% fragmentation)
 Jun 15 15:03:31 St-serv su: zimmer to root on /dev/ttyp0
 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT 
 I=1931747 (897632 should be 897600) (CORRECTED)
 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT 
 I=1931748 (1865184 should be 1865120) (CORRECTED)
 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT 
 I=2284637 (4 should be 0) (CORRECTED)
 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT 
 I=2284713 (4 should be 0) (CORRECTED)
 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: UNREF FILE I=23557  
 OWNER=root MODE=100644
 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: SIZE=0 MTIME=Jun  9 18:51 
 2012  (CLEARED)
 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: UNREF FILE I=1931319  
 OWNER=root MODE=100640
 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: SIZE=728 MTIME=Jul 26 17:37 
 2011  (CLEARED)
 ...
 
 
 I'v googled and found only one thread with su didnt'asking for password, 
 that one was abut jails, but this time we have a 100% garanty that we 
 didnt put any virtual enviroments.
 
 So the thing that scares is, mb this is symptop of server rootkit? (We'v 
 found nothing unusual in logs but it means nothing...) Or there is some 
 other explanation why su could not ask password?
 

The only thing I can think of ATM is .. did you recently perform and
upgrade from source with this system ? mergemaster ?

The reason why I ask is that when doing such things the master.passwd is
compared to the default master.passwd which has no passowrd set. If a
merge when wrong then there is a possibility that it was set back to
defaults by accident.

I also see that your system booted up and did a fsck(8). There is a
chance that something wierd happened here as well.

 
 Thanks in advance
 
 PS Duplicated question to freebsd-questions and freebsd-security because 
 unsure which one it should be send.
 
 
 ___
 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

-- 

 - (2^(N-1))
___
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: Default password hash

[Jason Hellenthal]

On Sat, Jun 09, 2012 at 12:04:25AM -0400, emu wrote:
 On 2012-06-09 00:01, Robert Simmons wrote:
  On Fri, Jun 8, 2012 at 9:06 AM, Maxim Khitrov m...@mxcrypt.com 
  wrote:
  On Fri, Jun 8, 2012 at 8:51 AM, Dag-Erling Smørgrav d...@des.no 
  wrote:
  We still have MD5 as our default password hash, even though 
  known-hash
  attacks against MD5 are relatively easy these days.  We've 
  supported
  SHA256 and SHA512 for many years now, so how about making SHA512 
  the
  default instead of MD5, like on most Linux distributions?
 
  If SHA-2 hashes have been supported for many years, why haven't the
  man pages been updated? login.conf(5) on 9.0-RELEASE still only 
  lists
  des, md5, and blf. I've been using the latter on my systems.
 
  Yes, I think at least listing all the supported algorithms in the
  login.conf man page is of utmost importance.  I've been using 
  blowfish
  since it was introduced to FreeBSD over 12 years ago, but I had no
  idea that any other algorithms were possible/available until now.

 it was listed with 9.0, change /etc/login.conf from md5 to sha512 and 
 then cap_mkdb /etc/login.conf and then passwd root/users for effect. as 
 a previous post im not sure the /etc/auth.conf is necessary.

AFAILR auth.conf was being deprecated and there was only one real user
of that left to eliminate. Whether that has been eliminated is beyond me
as I never tracked it... unimportant.

-- 

 - (2^(N-1))
___
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: periodic security run output gives false positives after 1 year

[Jason Hellenthal]

On Sat, Feb 18, 2012 at 04:35:20PM -0500, Robert Simmons wrote:
 On Fri, Feb 17, 2012 at 6:56 PM, Roger Marquis marq...@roble.com wrote:
  I don't personally recall a time when everything else wasn't logging the
  year, in one format or another.  That's not to imply that syslogs
  shouldn't be distinguishable by year but the question seems to be where
  the year should be logged, A) on every line or B) in the archive file
  name.
 
 There already is a standard, RFC 5424:
 freebsd-security@freebsd.org
 
 You are asking, should we make our own decision to do this totally
 differently than the standard set in that RFC, or should be implement
 that RFC?
 
 Another option is to do nothing and stick with the way it is.
 
 I think the way to proceed would be to implement RFC 5424, and have it
 as a switch in rc.conf, something like:
 
 syslogd_flags=-x
 where x is the new switch that would enable RFC5424 style logging.

How about a environment variable that login.conf could be adjusted for
so in-case something else wants to benefit from similiar behavior it can
just look for that too ? Similiar to how BLOCKSIZE works. After all this
is an environmental change.

 
 This would be optional for now.  Then with FreeBSD 10, 5424 would
 become the default with the option now being a flag -y to enable old
 style logging for backwards compatibility.
 
  I suspect it was not common practice to leave logs on the server for more
  than a year when Allman originally wrote syslog, and I have not seen an
  environment where logs are left in /var/log for over a year.  Personally,
  I would rather see FreeBSD stay backwards compatible and A) leave the
  syslog timestamp format alone instead opting for KIS by simply writing
  the year in the archive file name rather than wasting 5 bytes on every
  line of every syslog log file.  YMMV.
 
 It really shouldn't be a common practice, but we live in a world where
 governments are forcing data retention laws.  In is an unfortunate
 reality that needs to be dealt with.
 http://en.wikipedia.org/wiki/Telecommunications_data_retention
 
 Also, I'm not sure I follow the logic behind some of the people on
 this list saying not to implement this at all.  It should be an option
 for now, then the default on the other side of a major OS version with
 the old way then available as an option.  This seems the most rational
 path to take.
 ___
 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

-- 
;s =;


pgpBZkK3rmUTo.pgp
Description: PGP signature

Re: FreeBSD Security Advisory FreeBSD-SA-11:05.unix [REVISED]

[Jason Hellenthal]

Sorry but this security advisory has nothing to do with your misconfiguration 
of your system.

On Sun, Nov 20, 2011 at 11:18:33PM +, Richard M. Timoney wrote:
 As far as I can see the bug mentioned in the above advisory is not fully
 fixed.
 
 When logged in to a FreeBSD 8.2 machine with freshly updated /usr/src
 (world and kernel) [made on Wed Nov 16] via an XDMCP session, acroread
 says
 
 No protocol specified
 
 (acroread:2908): Gtk-WARNING **: cannot open display:
 pc200404.maths.tcd.ie:0.0
 
 Logged in to the same host via ssh -Y , I have DISPLAY set to something
 like localhost:10.0 and acroread does launch. It also launches on the
 console X display.
 
 I would be happy with pointers as to a fix for this.
 
 Yours,
 
 Richard Timoney
 
 -- 
 Richard M. Timoney
 (richa...@maths.tcd.ie)   Tel. +353-1-896 1196
 School of Mathematics, Trinity College, Dublin 2, Ireland
 WWW http://www.maths.tcd.ie/~richardt FAX  +353-1-896 2282
 ___
 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
___
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: PAM modules

[Jason Hellenthal]

On Sat, Sep 17, 2011 at 01:18:27AM -0400, Jason Hellenthal wrote:
 
 +1 for LDAP
 
 On Fri, Sep 16, 2011 at 10:25:16PM -0500, Brandon Gooch wrote:
  On Sep 16, 2011 10:21 AM, Dag-Erling Smørgrav d...@des.no wrote:
  
   We currently have a number of PAM modules in ports, and while some of
   them are specific to certain third-party software, many aren't.  I
   believe we would benefit from importing at least some of these into
   base.  My question is: which ones?
  
   DES
   --
   Dag-Erling Smørgrav - d...@des.no
  
  +1 for LDAP
  
  -Brandon
  ___
  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

Do not mean to reply to my own post but seems these offer the most IMHO
benefit to the project and end-users.

security/pam_jail A PAM module dropping users in jails after login
security/pam_krb5 A Pluggable Authentication Module for Kerberos5
security/pam_ldap A pam module for authenticating with LDAP
security/pam_mkhomedirCreate HOME with a PAM module on demand
security/pam_p11  A PAM module using crypto tokens for auth 
authenticate against Unix PAM
security/pam_pwdfile  A pam module for authenticating with flat passwd files
security/pam_require  A PAM module for restricting access based on unix 
group or username
security/pam_smb  NetBIOS domain logon PAM module
security/pam_ssh_agent_auth PAM module which permits authentication via 
ssh-agent
sysutils/pam_mountA PAM that can mount volumes for a user session
___
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: PAM modules

[Jason Hellenthal]

+1 for LDAP

On Fri, Sep 16, 2011 at 10:25:16PM -0500, Brandon Gooch wrote:
 On Sep 16, 2011 10:21 AM, Dag-Erling Smørgrav d...@des.no wrote:
 
  We currently have a number of PAM modules in ports, and while some of
  them are specific to certain third-party software, many aren't.  I
  believe we would benefit from importing at least some of these into
  base.  My question is: which ones?
 
  DES
  --
  Dag-Erling Smørgrav - d...@des.no
 
 +1 for LDAP
 
 -Brandon
 ___
 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
___
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: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)

[Jason Hellenthal]

Dag-Erling,

On Mon, May 09, 2011 at 02:34:14PM +0200, Dag-Erling Smørgrav wrote:
 Chris Rees utis...@gmail.com writes:
  This is the point I'm making, I can't recommend in the docs that one
  chmods $D/.. because we (the docs writers) don't know what the user
  (the reader) is going to set $D to.
 
 Ah, OK.  But you could provide an example where $D is /var/jail, or
 something along those lines.
 

Do you know if there is a way that chmod on / from within the jail could 
be prevented easily without breaking something ? Maybe not failing but 
falling though and return 0 for any operation with the sole argument of /.

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpkkDKXlMXYl.pgp
Description: PGP signature

Re: Rooting FreeBSD , Privilege Escalation using Jails (P�tur)

[Jason Hellenthal]

Jamie,

On Mon, May 09, 2011 at 12:55:06PM +0100, Jamie Landeg Jones wrote:
   A jail won't work for not-root users if the jail root directory is chmod 
   700 - although
   there is obviously a 'chroot' running withing the jail, the jailed user 
   still needs
   to have read permission from the hosts / -- chmod 700 therefore locks all 
   non-root
   users out.
  
 
  It's weird - I don't remember having such problem after setting jails'
  root directory permission to 700. I don't have the system anymore so I
  can't verify it just yet.
 
 I just tried it again (Freebsd 8.2) and I am wrong.
 
 Setting 700 on the jail root does indeed mess things up. But setting it on
 the parent (e.g. /usr/jails), and things are fine.
 
 Stupidly of me, that makes perfect sense. The non-privileged user needs
 read access to the jails /
 
 Sorry for the spam

In no-way is it spam. Consider it a 'test'imonial to others that may ask 
that question in the future ;)

Tip: Quick way to lock your system down to only root: ( chmod g= / ) 
***Emergency Use Only molly guard not present slippery when throbbed

Side effect of that is its not really nice for processes 
that run with lower privileges and isn't always apparent why things are 
not working correctly so its best to just use nologin or drop to SU. 

-- 

 Regards, (jhell)
 Jason Hellenthal



pgp62dnK4HPnB.pgp
Description: PGP signature

Re: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)

[Jason Hellenthal]

Edho,

On Sun, May 08, 2011 at 09:15:28AM +0700, Edho P Arief wrote:
 On Sun, May 8, 2011 at 5:31 AM, Jamie Landeg Jones ja...@bishopston.net 
 wrote:
  All the same, I've sent a PR [1] with some doc patches to make people
  more aware of this -- fulfilling my promise of 2+ years ago :S
 
  Thanks!
 
  Chris
 
  [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=156853
 
  Um. Some problems here.
 
  A jail won't work for not-root users if the jail root directory is chmod 
  700 - although
  there is obviously a 'chroot' running withing the jail, the jailed user 
  still needs
  to have read permission from the hosts / -- chmod 700 therefore locks all 
  non-root
  users out.
 
 
 It's weird - I don't remember having such problem after setting jails'
 root directory permission to 700. I don't have the system anymore so I
 can't verify it just yet.

It should also be noted here that the jailed root user also has permission 
to chmod(1) '/' to anything he or she wants unless you have taken 
precaution to not allow that. I would reccoment storing your jails two 
levels deep into a directory and chmod(1) 700 the first level to prevent 
access from the host and from the jailed root user changing the perms.

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpVO1qaQpzlX.pgp
Description: PGP signature

Re: Rooting FreeBSD , Privilege Escalation using Jails (P??????tur)

[Jason Hellenthal]

Chris,

On Sun, May 08, 2011 at 09:58:05AM +0100, Chris Rees wrote:
 On 8 May 2011 08:52, Jason Hellenthal jh...@dataix.net wrote:
 
  Edho,
 
  On Sun, May 08, 2011 at 09:15:28AM +0700, Edho P Arief wrote:
  On Sun, May 8, 2011 at 5:31 AM, Jamie Landeg Jones ja...@bishopston.net 
  wrote:
   All the same, I've sent a PR [1] with some doc patches to make people
   more aware of this -- fulfilling my promise of 2+ years ago :S
  
   Thanks!
  
   Chris
  
   [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=156853
  
   Um. Some problems here.
  
   A jail won't work for not-root users if the jail root directory is chmod 
   700 - although
   there is obviously a 'chroot' running withing the jail, the jailed user 
   still needs
   to have read permission from the hosts / -- chmod 700 therefore locks 
   all non-root
   users out.
  
 
  It's weird - I don't remember having such problem after setting jails'
  root directory permission to 700. I don't have the system anymore so I
  can't verify it just yet.
 
  It should also be noted here that the jailed root user also has permission
  to chmod(1) '/' to anything he or she wants unless you have taken
  precaution to not allow that. I would reccoment storing your jails two
  levels deep into a directory and chmod(1) 700 the first level to prevent
  access from the host and from the jailed root user changing the perms.
 
 
 Oops, you're absolutely right.
 
 I've updated the docs patches (links at [1]), though unfortunately it
 means it's a little less elegant; I'm reluctant to suggest
 
 # chmod 0700 $D/..
 

Haha I would strongly suggest against that ;) Not knowing where people are 
keeping the jails would impose quite a bit of harm if they did have them 
in places like that or /var/jailname. Unfortunately in this case we can 
only update the docs and hope that the user will keep up-to-date with 
reading them.

Only other possibility I see is ensuring that noone inside the jail can 
chmod or do anyting on / but this may actually be quite tough.

 in case someone sets $D to /usr/local/myjail or similar...
 
 Chris
 
 [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/156853

-- 

 Regards, (jhell)
 Jason Hellenthal



pgpdpA6vpno7J.pgp
Description: PGP signature