Re: FreeBSD Security Advisory FreeBSD-SA-22:15.ping
On Wed, Nov 30, 2022 at 05:03:10PM -0500, mike tancsa wrote: > On 11/30/2022 4:58 PM, Dev Null wrote: > > > > Easily to exploit in a test environment, but difficult to be exploited > > in the wild, since the flaw only can be exploited in the ICMP reply, > > so the vulnerable machine NEEDS to make an ICMP request first. > > > > The attacker in this case, send a short reader in ICMP reply. > > > Lets say you know that some device regularly pings, say 8.8.8.8 as part > of some connectivity check. If there is no stateful firewall, can the > attacker not just forge the reply on the chance their attack packet > could get there first ??? Or if its the case of "evil ISP" in the middle, > it becomes even easier. At that point, how easy is it to actually do > some sort of remote code execution. The SA implies there are mitigating > techniques on the OS and in the app.?? I guess its that last part I am > mostly unclear of, how difficult is the RCE if given the first > requirement as a given. It's probably also worth considering it as a local privilege escalation attack. The attacker will need to control a ping server, but it's often the case that enough ICMP traffic is allowed out for that to work and in that case they have unlimited tries to defeat any statistical mitigations (unless the admin spots all the ping crashes). -- Brooks signature.asc Description: PGP signature
Re: ASLR/PIE status in FreeBSD HEAD
On Mon, Apr 20, 2020 at 04:21:59PM +0200, Marcin Wojtas wrote: > Hi Ed, > > pt., 17 kwi 2020 o 15:52 Ed Maste napisa??(a): > > > > On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > > > > > Hi, > > > > > > Together with our customers, Semihalf is interested in improving the > > > status > > > of security mitigations enablement in FreeBSD. > > > > Happy to hear that there's interest in this work! > > > > > 1. Are there any hard blockers, like missing features or bugs, that > > > prevent > > > enabling ASLR by default in the kernel and building the base system with > > > -DWITH_PIE? > > > > I believe there are no showstopper issues but there are a some > > prerequisites. One is that there are some applications that may > > misbehave with randomization enabled. They would need to be > > identified, and tagged (with the elfctl tool now in the base system). > > I was thinking if it is possible to come up with such wide test > coverage to test every single application from the base system. Do you > think it is achievable or should we rather follow the approach to do > as many tests as possible, but rely on the community feedback to catch > the corner cases (like the ntpd issue mentioned in this thread)? > What about the ports? If we gate on full testing we'll never move forward. We had a GSoC project a few years ago to try to generate lame tests for each program, if someone picked that up, we could get better coverage fairly quickly, but it would still be far from complete. Our best bet is probably to make it easy for people to test and to try and recruit testers in the community (this is especially true for ports). -- Brooks signature.asc Description: PGP signature
Re: SQLite vulnerability
On Sun, Dec 16, 2018 at 08:13:59AM -0800, Roger Marquis wrote:
> Thanks to Chrome{,ium} a recently discovered SQLite exploit has been all
> over the news for a week now. It is patched on all Linux platforms but
> has not yet shown up in FreeBSD's vulxml database. Does this mean:
>
> A) FreeBSD versions prior to 3.26.0 are not vulnerable, or
>
> B) the ports-secteam is not able to properly maintain the vulnerability
> database?
>
> If the latter perhaps someone from the security team could let us know
> how such a significant vulnerability could go unflagged for so long and,
> more importantly, what might be done to address the gap in reporting?
Almost certainly:
C) This vunerability was reported in a random blog post on a Sunday
without any details so people haven't caught up with it yet.
-- Brooks
signature.asc
Description: PGP signature
Re: Interim support guarantee for FreeBSD 12
It concerns all produces created from the STABLE branch include releases. We're aiming to begin discussions starting around the first of the year. -- Brooks On Fri, Nov 30, 2018 at 03:47:07PM -0800, Roger Marquis wrote: > FYI re potential cuts to STABLE long-term support. Does this affect the > RELEASE branch as well? Anyone know where this is being discussed? The > announcement mentions community feedback but that seems unlikely given > there has been no mention of it on the freebsd-security list. > > Roger Marquis > > > >Date: Wed, 28 Nov 2018 11:04:48 -0400 > >From: FreeBSD Core Team Secretary > >To: freebsd-annou...@freebsd.org > >Subject: [FreeBSD-Announce] Interim support guarantee for FreeBSD 12 > > > >Dear FreeBSD community, > > > >The Core Team, in consultation with Release Engineering, the Security > >Team, and Port Manager has decided that we need to reevaluate the 5-year > >support of stable branches starting with stable/12. A changed security > >landscape, increased toolchain velocity, and shorter support windows for > >our upstream components necessitate this reevaluation. > > > >We will be leading discussions on updating our support model, with the > >goal of making the model sustainable for the Project. These > >discussions, which will include opportunities for community feedback, > >will be complete by March 31, 2019. > > > >Regardless of the outcome of the discussions, we guarantee support for > >the stable/12 branch for at least 18 months, or at least 6 months after > >13.0 is released, whichever is later. Again, these are minimum > >durations for the stable/12 branch support and they will not be reduced. > > > >After these discussions are complete, there will be a revised statement > >about the stable/12 branch lifetime. > > > >Release Engineering, the Security Team, Port Manager, and the Core Team > ___ > 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" > signature.asc Description: PGP signature
Re: OpenSSH HPN
On Tue, Nov 24, 2015 at 09:29:44PM +0100, Aaron Zauner wrote: > Hi, > > Please forgive my ignorance but what's the reason FreeBSD ships > OpenSSH patched with HPN by default? Besides my passion for > security, I've been working in the HPC sector for a while and > benchmarked the patch for a customer about 1.5 years ago. The > CTR-multi threading patch is actually *slower* than upstream OpenSSH > with AES in CTR mode. GCM being, of course, the fastest mode on > AESNI plattforms. We never imported the AES bits as they were broken and AESNI was available. > The NULL mode is a security concern as some have noted, I can only > imagine that the window-scaling patch is of such importance? Both NULL and window-scaling were merged because both are useful in some environments. -- Brooks signature.asc Description: PGP signature
Re: OpenSSH HPN
On Tue, Nov 10, 2015 at 04:40:42PM -0800, Bryan Drewery wrote: > On 11/10/15 1:42 AM, 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). > > I had this same problem as well, but have since reworked the HPN patch > for ports to be more easily maintained. I've considered offering or > just updating the base SSH, but have not since we have random changes in > the HPN functionality in base that would be lost. We for some reason > decided we were going to maintain our own version and not even upstream > the changes to the HPN authors which has contributed to this situation. We had ever intention of upstreaming our cleaned up HPN patches and some interest from OpenSSH devs to take the window scaling portion of the patch upstream, but other things intruded and we never found time to complete that work. I think both the window scaling and NONE cipher changes are useful, but do not have time to do anything with them. I'm fine with them being removed from base and replaced or just dropped if they are in the way of progress. -- Brooks signature.asc Description: PGP signature
Re: New vulnerabilities in file(1)
On Thu, Jan 08, 2015 at 09:00:33PM +0100, Piotr Kubaj wrote: > See http://mx.gw.com/pipermail/file/2014/001653.html and > http://mx.gw.com/pipermail/file/2014/001654.html for reports. > They're fixed in > https://github.com/file/file/commit/ce90e05774dd77d86cfc8dfa6da57b32816841c4 > and > https://github.com/file/file/commit/65437cee25199dbd385fb35901bc0011e164276c It looks like these are both addressed in file 5.22 which is in HEAD and is scheduled to be MFC'd in another week. -- Brooks pgp4k7t2GTbyM.pgp Description: PGP signature
Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update]
On Thu, Apr 10, 2014 at 06:38:39PM -0500, Bryan Drewery wrote: > On 4/10/2014 12:03 PM, David Noel wrote: > > I found a few bugs in portsnap and freebsd-update that I'd like to > > bring to the community's attention and hopefully recruit people to > > help fix. I mentioned them to Colin (their author) a few years ago and > > he agreed that they're issues that need to be addressed, but in the > > time since neither he nor I have been able to get around to fixing > > them. I'm hoping that someone reading this is able and willing to > > pitch in. I've also taken this to secteam@, but no one there's made > > any progress on them in the past 6 months so I figured it was time to > > approach the broader community. Surely there's a benevolent sh-savvy > > hacker out there who has time to take these on. They're pretty simple > > fixes -- the functionality that's needed exists in the scripts > > already, it just needs to be reused in a few key places. > > > > I also think it would be an appropriate time to discuss retiring portsnap. > > > > [snip] > > > > > With the inclusion of svnlite in 10 I think the valid question comes > > up as to whether we really need the portsnap system or whether it > > could be safely retired. Obviously if the conclusion of that > > discussion is that we don't need it then these bug fixes would be > > unnecessary. > > > > The reason I see for it to be retired is that subversion allows us to > > easily and securely check out the ports tree. It's a one-line command: > > `svn co https://...`. Keeping it up-to-date it is another one-liner: > > `cd /usr/ports; svn update`. With the inclusion of svnlite in base, > > the portsnap code and servers acting as mirrors become redundant and > > seem like a waste of resources. > > Your report aside, I find portsnap to be far superior in security for > ports and users. I wish it knew how to checkout source as well. > > 1. It only allows a secure checkout. You can't accidentally checkout > svn:// or http://. > 2. It blows away directories with updates. I've witnessed a trojaned > ports checkout before. 'svn update' does not remove unexpected files, > nor remove changes. Yes this is a decrease in usability when you've > modified the file and want to keep the changes, but you can easily make > a wrapper script to merge in your changes, or use SVN if you really want. > 3. SVN too often gets into confusing situations on 'svn update' that > require knowledge of how SVN works to resolve the conflict. Even I with > my ~10 years of SVN experience I get confused often and frustrated when > not even 'svn revert -R dir; svn up dir' will revert to the upstream > version (I may have my example off, but that's the point, it's confusing.) > 4. SVN asks the user to confirm the public key when first using the > HTTPS repository. I worry this step will be done poorly by users. > 5. SVN requires 'svn upgrade' sometimes, this is also confusing for users. > 6. The way we do HTTPS is through mirrors only, if you pick the wrong > mirror it's against hard for the user who doesn't know SVN to change to > a different mirror. Portsnap already handles mirrors excellently by geo > location. > > Teaching portsnap how to speak SVN, while still behaving the same, may > cover my concerns. > > To be fair SVN does have its advantages: > > 1. Quicker updates for users. > 2. Easier patch generation for PR submission. > 3. Similarly, viewing your changes more easily. I agree with your analysis. For systems where I'm not developing ports I much prefer portsnap. I'd also add that SVN has limited integrity insurance so even if you verify the certificate you're relying exclusively on SSL/TLS to ensure correct transmission. This year alone much less the whole history of SSL implementations suggests this isn't the best place to put a single point of failure. -- Brooks pgpOsWjaR29XO.pgp Description: PGP signature
Re: MITM attacks against portsnap and freebsd-update
[Trimming the list to -security plus Colin in hopes of reducing the number of partial conversations. Sending to four lists and an alias is a list etiquette violation.] [Also dropping the discussion of replacing portsnap since that is a mostly unrelated discussion.] On Thu, Apr 10, 2014 at 12:03:45PM -0500, David Noel wrote: > Problem Summary > > 1. Both portsnap and freebsd-update extract fetched data prior to its > SHA256 verification. The extraction libraries used have a long history > of bugs so it's reasonable to assume there might be more. Both > freebsd-update and portsnap are run as root. Using a vulnerability in > the decompression libraries an attacker who was MITM-capable could > compromise any FreeBSD system running portsnap or freebsd-update. > 2. The portsnap mirroring script (pmirror.sh) lacks of any sort of > mechanism to verify the data prior to processing and mirroring it. > Without this, mirrors are open to compromise via methods similar to > those found in the client-side scripts (decompression library > exploitation). It also means an attacker could feed a mirror a corrupt > archive, opening users of that mirror to compromise. These seem like serious issues and a verify-first design would have been better. That said, I'm not convinced that a rototil of the protocol and all the associated storage duplication is worth the effort. It's better in my mind to commit one of the patches to sandbox gzip with Capsicum which will protect from everything except filling the disk by denying gunzip the ability to do anything but write to the file opened by the script. That will protect all gzip users. > 3. Both portsnap and freebsd-update are vulnerable to freeze attacks. What do you mean by a freeze attack? I'm not familiar with this term and I didn't find this post, the PRs, or a quick Google search illuminating. -- Brooks pgpx9sqWDt_0g.pgp Description: PGP signature
Re: Capsicum and sendto(2)
On Tue, Jan 21, 2014 at 10:45:11PM +0900, KAMADA Ken'ichi wrote: > Hi, > > What is the intended behavior of sendto() with non-NULL destination > when the capability mode is enabled? > > If the capability mode is *not* enabled, it is checked against > CAP_CONNECT in kern_sendit() @ uipc_syscall.c. > This matches the explanation in the rights(4) manual page. > > However, if the capability mode is enabled, it is always > rejected in sendit(). Is this intended? Yes, this is intended. In capabilty mode all access to namespaces is restricted including the IP address namespace. You must either connect your sockets before entereing capabilty mode or use casper to provide connected sockets. -- Brooks pgpSXxsQvSlcQ.pgp Description: PGP signature
Re: Request for review: Sandboxing dhclient using Capsicum.
On Sun, Jun 09, 2013 at 12:33:46AM +0200, Pawel Jakub Dawidek wrote: > I'd appreciate any review, especially security audit of the proposed > changes. The new and most critical function is probably send_packet_priv(). I've looked over the diff and not found any significant issues, but have a few comments in order of most to least important. In change 229477 using a cached hostname may change behavior if the host is renamed as a result of dhclient operation. The new behavior might be more correct, at least it would be if we reliably restored the host name on termination. I think the change is fine, but we should be keep an eye out for problem reports. In change 229476 I noticed there is a constant 0x1fff that you've moved around. It was already there, but it seems like an unnecessary magic number. In the send_packet_* function declarations in dhcpd.h, you have included variable names which is inconsistent with the surrounding definitions. I saw a few style/whitespace fixed mixed in that should be batched, probably before the substantive commits. -- Brooks ___ 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
On Tue, Sep 20, 2011 at 05:21:03PM -0700, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 09/20/11 15:51, Kostik Belousov wrote: > [...] > > Yes, the question of maintanence of the OpenLDAP code in the base > > is not trivial by any means. I remember that openldap once broke > > the ABI on its stable-like branch. > > That happen a few times however these are either not essential client > library (libldap and liblber) API or it's not changing parameters or > removing interfaces. Moreover, like the base libbsdxml.so, it's only > intended to be used by base system only so it's relatively easier to > maintain ABI stability, e.g. we can probably just expose only symbols > that we use, etc. > > > Having API renamed during the import for the actively-developed > > third-party component is probably a stopper. I am aware of the > > rename done for ssh import in ssh_namespace.h, but I do not think > > such approach scale. > > That's right. We did use a similar approach but again, if it's just > libldap and liblber, the change would be quite slow over years. We do > need to patch files. > > > Would the import of openldap and nss + pam ldap modules in src/ > > give any benefits over having openldap and ldap nss + pam modules > > on the dvd1 ? > > Well, for ldap nss + pam models, people usually want them to "just > work" rather than wanting new features provided by a port installed > OpenLDAP. That's said, the user expects he can update any port > without risking into being locked out from the system plus these > modules can be upgraded or updated with existing binary update mechanisms. This is certainly the largest benefit. I used a variant of pam_ldap for authentication at $WORK for many years and the instability of the OpenLDAP API was a constant headache. That isn't to say that importing it into base is the only possible solution. It is likely the most straightforward. -- Brooks pgp4NpQbB4CKt.pgp Description: PGP signature
Re: SSL is broken on FreeBSD
On Fri, Apr 01, 2011 at 12:33:30PM -0400, Robert Simmons wrote: > Now, you are also not satisfied with the CA bundle in the ports > collection because it does not contain the CA that you need. I'm not > sure which one it is that you need. But a good place to start is > here: > http://www.mail-archive.com/modssl-users@modssl.org/msg16980.html > > That contains a perl script for extracting the CA bundle from > Mozilla's CVS. At first glance, it may frustrate you, because it may > not be obvoius where it connects to (that info is obscured). However, > look at the following help file. It has all the connection details > for mozilla's cvsroot that you will need. Just substitute the > "anonym...@cvs-mirror.mozilla.org" for "[EMAIL PROTECTED]" in the > script. > https://developer.mozilla.org/en/Mozilla_Source_Code_Via_CVS The point of security/ca_root_nss is that it is exactly the set of certs trusted by Mozilla (via the nss library) via the mechanism described above. The FreeBSD Project makes no warranty that it is a good set to trust. It just happens to be a set that is widely trusted. > If you are not satisfied with Mozilla's bundle, you can find google > Chrome's list here somewhere: > http://src.chromium.org/viewvc/chrome/ We might actually want to maintain a port of those as well if they differ in any meaningful way. -- Brooks pgp4L05xwjbIq.pgp Description: PGP signature
Re: freebsd-update-server source code
On Sat, Jan 24, 2009 at 09:37:22AM +0100, Victor Balada Diaz wrote: > Hello, > > I know on CVS the source code of freebsd-update is in > projects/freebsd-update-server but i can't find where is it > now with svn. I've looked at base/projects/ but it's not there. > > Can anyone point me where can i find the latest source of > freebsd-update-server? base/projects is seperate from the projects repository which remains under cvs. The old cvs path remains valid. -- Brooks pgpZuSaTN3Eqv.pgp Description: PGP signature
Re: [patch] libc Berkeley DB information leak
On Thu, Jan 15, 2009 at 05:21:42PM +0100, Arnar Mar Sig wrote:
> Would it not be better to remove the PURITY define all together and always
> have the memset()'s there or changing the malloc()s to calloc() if there is
> no special reason for the 0xFF in memset.
>
> Can anyone say they would rather have the possibility of sensitive
> information leek from every app using dbopen versus the small speed down
> from always having the memset?
Given that people who care about performance are almost certaintly using one of
the newer BDB release from ports, this seems logical to me.
-- Brooks
> Greets
> Arnar Mar Sig
> Valka ehf
>
> On Jan 15, 2009, at 3:45 PM, Jaakko Heinonen wrote:
>
>>
>> Hi,
>>
>> FreeBSD libc Berkeley DB can leak sensitive information to database
>> files. The problem is that it writes uninitialized memory obtained from
>> malloc(3) to database files.
>>
>> You can use this simple test program to reproduce the behavior:
>>
>> http://www.saunalahti.fi/~jh3/dbtest.c
>>
>> Run the program and see the resulting test.db file which will contain a
>> sequence of 0xa5 bytes directly from malloc(3). (See malloc(3) manual
>> page for the explanation for the "J" flag if you need more information.)
>>
>> This has been reported as PR 123529
>> (http://www.freebsd.org/cgi/query-pr.cgi?pr=123529) which contains a
>> real information leak case. The PR is assigned to secteam and I have
>> also personally reported it to secteam but I haven't heard a word from
>> secteam members.
>>
>> A code to initialize malloc'd memory exists but the feature must be
>> enabled with PURIFY macro. With following patch applied
>> the test program doesn't output 0xa5 bytes to the database file:
>>
>> %%%
>> Index: lib/libc/db/hash/hash_buf.c
>> ===
>> --- lib/libc/db/hash/hash_buf.c (revision 187214)
>> +++ lib/libc/db/hash/hash_buf.c (working copy)
>> @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$");
>> #include
>> #include
>> #include
>> +#include
>>
>> #ifdef DEBUG
>> #include
>> Index: lib/libc/db/Makefile.inc
>> ===
>> --- lib/libc/db/Makefile.inc (revision 187214)
>> +++ lib/libc/db/Makefile.inc (working copy)
>> @@ -3,6 +3,8 @@
>> #
>> CFLAGS+=-D__DBINTERFACE_PRIVATE
>>
>> +CFLAGS+=-DPURIFY
>> +
>> .include "${.CURDIR}/db/btree/Makefile.inc"
>> .include "${.CURDIR}/db/db/Makefile.inc"
>> .include "${.CURDIR}/db/hash/Makefile.inc"
>> %%%
>>
>> Could someone consider committing this or some other fix for the
>> problem?
>>
>> --
>> Jaakko
>> ___
>> 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"
>
pgpnxtuFCrG3S.pgp
Description: PGP signature
Re: FreeBSD Security Advisory FreeBSD-SA-09:02.openssl
On Thu, Jan 08, 2009 at 08:53:17PM +0100, Zahemszky G?bor wrote: > Hi! > > Neither the lukemftpd, nor the openssl advisory speaks about > freebsd-update as an upgrade solution. (And I couldn't update with > it.) Why? I'm not sure what it wasn't mentioned, but it worked just fine for a dozen boxes at work. -- Brooks pgpC3HPU0gCso.pgp Description: PGP signature
Re: machine hangs on occasion - correlated with ssh break-in attempts
On Thu, Aug 21, 2008 at 10:10:42PM +0200, Rink Springer wrote: > On Thu, Aug 21, 2008 at 01:03:09PM -0700, Jeremy Chadwick wrote: > > Finally, consider moving to pf instead, if you really feel ipfw is > > what's causing your machine to crash. You might be pleasantly surprised > > by the syntax, and overall administrative usability (it is significantly > > superior to ipfw, IMHO). > > In fact, pf can already do this out-of-the-box, by doing something like: > > table persist > pass quick on $wan_if proto tcp from any to any port ssh flags S/SA keep > state \ > (max-src-conn 15, max-src-conn-rate 5/3, overload flush > global) > > If that is not an option, I have found that security/denyhosts works > pretty well too (it just adds IP's to /etc/hosts.deniedssh, and > host_access(5) denies them based on this) You almost certainly don't want to rate limit ssh connections, only failed ones. If you rate limit connections and use svn, you're likely to lock your self out. -- Brooks pgpMAJrLs64lu.pgp Description: PGP signature
Re: post-reload SSH server key transfer ... comments ?
On Mon, Feb 05, 2007 at 05:51:38PM -0800, Arone Silimantia wrote: > > I am going to be replacing system X with system Y (which is much > faster, newer). > > I will load up the new system from scratch, and then just copy over > the user data from the old system. Then I will turn off the old > system for good, and set the IP and hostname of the new system to > match the old one. > > Easy. Except everyones ssh connections will complain loudly about > potential MITM attacks, etc. ... > > So, am I correct that I can just tar up /etc/ssh on the old system and > use it to overwrite /etc/ssh on the new system, and that's that ? No > warning message or other problems ? Yes. Actually, the files you need are "/etc/ssh/*_key /etc/ssh/*_key.pub". The others may contain settings you want to move, but don't effect the machine's ssh identity. > ALSO, am I correct that if I copy over their home directories that > contain their ~/.ssh/authorized_keys that those will continue to work > just fine even though they are on a new server ? Yes, they contain no knowledge of the server they are on. -- Brooks pgpjPXQ5LBFC5.pgp Description: PGP signature
Re: seeding dev/random in 5.5
On Wed, Aug 09, 2006 at 09:29:44AM -0400, fwaggle wrote: > Brooks Davis wrote: > >On Wed, Aug 09, 2006 at 12:17:35AM -0700, R. B. Riddick wrote: > >>--- Doug Barton <[EMAIL PROTECTED]> wrote: > [snip] > >>* I received a private communication yesterday about this matter. But the > >>list > >>did not. I will cite (not litterally) a little bit out of that message: > >>Since > >>you do not know anything about the remotely created host-key, u cannot > >>connect > >>safely to the freshly installed box, because: You do not even know the > >>signature of the new host-key, so that if u connect to the wrong box u > >>would > >>not even known. Workaround: You could give all hosts the same well-known > >>host-key (via your install-image-CD) and then u could change the host-key > >>in a > >>remotely controlled way individually and note down the signature? Maybe my > >>secret informer (lets call him Rasmus or RK) wants to come public... :-) > > > >These are valid if probably overly paranoid points. :) > [/snip] > > i have a question. perhaps i'm misunderstanding something with how SSH > works, but how would having a "standard freebsd private key" benefit > anyone? if you wanted to impersonate a newly installed freebsd machine, > then all you'd need is that freely-available private key. plus you'd get > a bunch of clueless admins who had their machines installed by a > dedicated server provider, and who'd never change their host key, which > would effectively ruin SSH for their purposes. > > unless i've seriously missed the boat somewhere (it's happened before!) > i think a better solution would still be random key generation with a > nice little option to email the key signature somewhere that the new > admin could pick it up. it's still fraught with impersonation danger for > the paranoid, but imo it's a better idea than having a not-so-private > key on install. I interpreted the suggestion is something to be done via custom install media. There's no chance in hell the freebsd project would install a default key since it's such an obviously bad idea. -- Brooks pgp3xI6AdnxkQ.pgp Description: PGP signature
Re: seeding dev/random in 5.5
On Wed, Aug 09, 2006 at 12:17:35AM -0700, R. B. Riddick wrote: > --- Doug Barton <[EMAIL PROTECTED]> wrote: > > The patches you sent to implement this option didn't come through to the > > mailing list, could you resend them please? :) > > > > Seriously though, a lot of people looked at this problem when yarrow was > > introduced, and no solution became immediately apparent. So, if someone > > wants to take a crack at implementing something, knock yourself out. > > > Since this is the security mailing list, I would like to direct the attention > on the following points: > > * I see in the CD-procedure the problem, that a postman, who is more > sophisticated than in Leslie Nielsen's "Naked Gun 33 1/3" movie, might > exchange > the media, so that u let ur Netherlandish install something u dont know and/or > like. Workaround: Do you use a checksum over the media (`md5 < /dev/acd0`) and > transmit those checksum on a different way (maybe email)? > > * I received a private communication yesterday about this matter. But the list > did not. I will cite (not litterally) a little bit out of that message: Since > you do not know anything about the remotely created host-key, u cannot connect > safely to the freshly installed box, because: You do not even know the > signature of the new host-key, so that if u connect to the wrong box u would > not even known. Workaround: You could give all hosts the same well-known > host-key (via your install-image-CD) and then u could change the host-key in a > remotely controlled way individually and note down the signature? Maybe my > secret informer (lets call him Rasmus or RK) wants to come public... :-) These are valid if probably overly paranoid points. :) > * But what if the postman (see first point) know already the host-key from > reading the CD? Then he could log in to ur boxes... This isn't true. The host key lets you impersonate the host. It does not do anything related to log in (unless you use host based auth). -- Brooks pgpZQ6Hj9Rr6C.pgp Description: PGP signature
Re: Encrypted volume - how?
On Mon, Jan 23, 2006 at 09:39:52AM +1100, Norberto Meijome wrote: > Hi all, > I'm looking for a way to recreate the functionality of PGP Disk (under > Win32). Basically, create an encrypted file, which contains a filesystem > which can then be mounted in any mount point. > > I know I can use GELI in FreeBSD 6 - as I understand, it performs the > encryption at the partition level (the whole partition is encrypted). > I'd like to be able to simply unmount my 'secure volume', and be able to > back it up as a whole, or move it to another computer without having to > repartition the destination. I think GELI wouldn't be good for this. GELI or GBDE are probably what you're looking for, you just need to use mdconfig to create a vnode (file) backed disk image which you will encrypt and then create a file system on. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpWR1HYQcltP.pgp Description: PGP signature
Re: ee using 99% cpu after user ssh session terminates abnormaly
On Thu, Sep 08, 2005 at 08:27:13AM +1000, talonz wrote: > Recently i have been using a dialup 56k account to access the net > and have noticed that when my ssh session times out and I am editing > a file in ` ee ' the system goes to 99% cpu usage and stays like > this till the pid is killed. > This is a standard user account (not root/su) > > Would a user be able to create a denial of service condition > on the remote system using this bug? No more then they could with the ablity to run any other program that loops. > (sorry if this is posted to the incorrect list) > > Details: > > System - FreeBSD 5.4-RELEASE-p5 > > ee using 99% cpu after user session terminates abnormaly > PID reported by top. > > The output from ps looks like this > > [EMAIL PROTECTED] ps aux| grep 70464 > someuser 70464 93.5 0.1 1920 1372 p1- R 7:09PM 687:07.27 ee file I can't seem to trigger this bug on a 7.0 machine either by killing the client or using tcpdrop to kill the tcp session. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpdIHFCyAGrO.pgp Description: PGP signature
