Re: update - Re: Facebook post-mortems...

>> Fairly abstract - Facebook Engineering - >> https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10158791436142200%7D&path=%2Fnotes%2Fnote%2F&_rdr >> > > My bad - might be best to ignore

Re: update - Re: Facebook post-mortems...

On 10/4/21 6:07 PM, jcur...@istaff.org wrote: On 4 Oct 2021, at 8:58 PM, jcur...@istaff.org wrote: Fairly abstract - Facebook Engineering - https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10158791436142200%7D&path=%2Fnotes%2Fnote%2F&_rdr

Re: Update your ARIN IRR data access methods (was: Fwd: [arin-announce] New Internet Routing Registry Release)

Hello - The 'whois.radb.net' IRR instance and the RADb services have been updated to reflect ARIN's IRR updates. - - Mitchell Mitchell Kuch and the RADb Team On Wed, Jun 10, 2020 at 2:54 PM John Curran wrote: > > NANOGers - > > ARIN has released its updated IRR system - if you are relying on A

Re: Update your ARIN IRR data access methods (was: Fwd: [arin-announce] New Internet Routing Registry Release)

Dear John, group, On Wed, Jun 10, 2020 at 06:51:53PM +, John Curran wrote: > ARIN has released its updated IRR system - if you are relying on > ARIN’s IRR data, please refer to details below and update access > methods accordingly. Ack - NTT has done so. The 'rr.ntt.net' instance now carries

Re: Update to BCP-38?

53 To: nanog@nanog.org Subject: RE: Update to BCP-38? On Tuesday, 8 October, 2019 11:03, William Herrin wrote: >Limiting the server banner so it doesn't tell an adversary the exact OS- >specific binary you're using has a near-zero cost and forces an adversary >to expend mor

Re: Update to BCP-38?

On Tue, 8 Oct 2019 13:59:58 +, Mark Collins may have written: > Not everyone attacking your systems is going to have the skills or > knowledge to get in though - simple tricks (like hiding what web server > you use) can prevent casual attacks from script kiddies and others who > aren't committ

Re: Update to BCP-38?

On Tue, Oct 08, 2019 at 10:03:16AM -0700, William Herrin wrote: > Limiting the server banner so it doesn't tell an adversary the exact > OS-specific binary you're using has a near-zero cost and forces an > adversary to expend more effort searching for a vulnerability. Why would they bother perform

RE: Update to BCP-38?

od (2) instead. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: Mark Collins >Sent: Tuesday, 8 October, 2019 12:17 >To: Keith Medcalf ; nanog@nanog.org >Subject: Re: Update

Re: Update to BCP-38?

On Tue, 08 Oct 2019 11:53:33 -0600, "Keith Medcalf" said: > So while the cost of doing the thing may be near-zero, it is not zero. And in fact, there's more than just the costs of doing it. There's also the costs of having done it. Obfuscating your OpenSSH versions is a *really* good way to mak

RE: Update to BCP-38?

On Tuesday, 8 October, 2019 11:03, William Herrin wrote: >Limiting the server banner so it doesn't tell an adversary the exact OS- >specific binary you're using has a near-zero cost and forces an adversary >to expend more effort searching for a vulnerability. It doesn't magically >protect you f

Re: Update to BCP-38?

On Tue, Oct 8, 2019 at 6:51 AM Rich Kulawiec wrote: > On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote: > > You've ignored step 1 - identifying critical information that needs > > protecting. It makes sense to protect information that needs protecting and > > don't lose slee

RE: Update to BCP-38?

>Not everyone attacking your systems is going to have the skills or >knowledge to get in though - simple tricks (like hiding what web server >you use) can prevent casual attacks from script kiddies and others who >aren't committed to targeting you, freeing your security teams to focus >on the serio

RE: Update to BCP-38?

n the serious threats. Mark -Original Message- From: NANOG On Behalf Of Rich Kulawiec Sent: 08 October 2019 14:51 To: nanog@nanog.org Subject: Re: Update to BCP-38? On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote: > You've ignored step 1 - identifying critica

Re: Update to BCP-38?

On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote: > You've ignored step 1 - identifying critical information that needs > protecting. It makes sense to protect information that needs protecting and > don't lose sleep over information that doesn't need protecting. Not many of

Re: Update to BCP-38?

As an Evil Firewall Administrator™, I have an interest in this area ... On Fri, 4 Oct 2019 15:05:29 -0700, William Herrin may have written: > On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf wrote > > Anyone who says something like that is not a "security geek". They are > > a "security poser", int

Re: Update to BCP-38?

- Original Message - > From: "Stephen Satchell" > On 10/3/19 10:13 PM, Fred Baker wrote: >> There is one thing in 1122/1123 and 1812 that is not in those kinds >> of documents that I miss; that is essentially "why". Going through >> 1122/1123 and 1812, you'll ind several sections that say

RE: Update to BCP-38?

On Friday, 4 October, 2019 16:05, William Herrin wrote: >On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf wrote: >> On Thursday, 3 October, 2019 11:50, Fred Baker >> wrote: >>> A security geek would be all over me - "too many clues!". >> Anyone who says something like that is not a "security

Re: Update to BCP-38?

On Sat, 05 Oct 2019 07:01:58 +0900, Masataka Ohta said: > One of a stupidity, among many, of IPv6 is that it assumes > links have millions or billions of mostly immobile hosts Can somebody hand me a match? There's a straw man argument that needs to be set afire here. pgp1MMtG4U3Ba.pgp Descrip

Re: Update to BCP-38?

On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf wrote > On Thursday, 3 October, 2019 11:50, Fred Baker > wrote: > > A security geek would be all over me - "too many clues!". > > Anyone who says something like that is not a "security geek". They are a > "security poser", interested primarily in "se

Re: Update to BCP-38?

Mark Andrews wrote: Look at CableLabs specifications. There is also RFC 7084, Basic Requirements for IPv6 Customer Edge Routers which CableLabs reference. One of a stupidity, among many, of IPv6 is that it assumes links have millions or billions of mostly immobile hosts and define very large

Re: Update to BCP-38?

Look at CableLabs specifications. There is also RFC 7084, Basic Requirements for IPv6 Customer Edge Routers which CableLabs reference. Also RFC 8585, Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service Mark > On 5 Oct 2019, at 12:00 am, Stephen Satchell wrote: > > On 10/

Re: Update to BCP-38?

On 10/3/19 10:13 PM, Fred Baker wrote: > There is one thing in 1122/1123 and 1812 that is not in those kinds > of documents that I miss; that is essentially "why". Going through > 1122/1123 and 1812, you'll ind several sections that say "we require > X", and follow that with a "discussion" section

Re: Update to BCP-38?

On Oct 3, 2019, at 3:15 PM, Stephen Satchell wrote: > You still need a IPv6 version of RFC 1812. If we were to start with the current draft, I would probably want to start over, and have people involved from multiple operators. That said, let me give you some background on RFC 1812. The develop

Re: Update to BCP-38?

Valdis Kletnieks wrote: I suppose you never considered that in the 11 years intervening, we decided that maybe things should be done differently. I never considered? I even know that it is called second system syndrome. Do you? Masataka Ohta

Re: Update to BCP-38?

On Fri, 04 Oct 2019 08:20:22 +0900, Masataka Ohta said: > As for requirements for IPv6 routers, how do you think about the > following requirement by rfc4443? 3 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M. G

Re: Update to BCP-38?

Stephen Satchell wrote: You still need a IPv6 version of RFC 1812. Make it as clean as possible. Use an ax instead of a XACTO knife on the current draft. What is the minimum necessary things that a generic IPv6 router MUST do? As for requirements for IPv6 routers, how do you think about the

Re: Update to BCP-38?

On 10/3/19 2:07 PM, Mark Andrews wrote: > Now IPv6 examples are nice but getting several 1000’s people to read draft > that > just add addresses in the range 2001:DB8::/32 instead of 11.0.0.0/8, > 12.0.0.0/8 > and 204.69.207.0/24, then to get the RFC editor to publish it is quite frankly > is a w

Re: Update to BCP-38?

On Thu, 03 Oct 2019 15:28:30 -0600, "Keith Medcalf" said: > On Thursday, 3 October, 2019 11:50, Fred Baker > wrote: > > A security geek would be all over me - "too many clues!". > Anyone who says something like that is not a "security geek". They are a > "security poser", interested primarily i

RE: Update to BCP-38?

On Thursday, 3 October, 2019 11:50, Fred Baker wrote: > A security geek would be all over me - "too many clues!". Anyone who says something like that is not a "security geek". They are a "security poser", interested primarily in "security by obscurity" and "security theatre", and have no

Re: Update to BCP-38?

> On 4 Oct 2019, at 12:10 am, Marco Davids (Private) via NANOG > wrote: > > > On 03/10/2019 15:51, Stephen Satchell wrote: > >> For a start, *add* IPv6 examples in parallel with the IPv4 examples. > > 1000 times +1 > > We need (much) more IPv6 examples! Have you read BCP-38? Is there an

Re: Update to BCP-38?

On Oct 3, 2019, at 12:30 PM, Stephen Satchell wrote: > > On 10/3/19 8:22 AM, Fred Baker wrote: >> And on lists like this, I am told that there is no deployment - that >> nobody wants it, and anyone that disagrees with that assessment has >> lost his or her mind. That all leaves me wondering whic

Re: Update to BCP-38?

Sent from my iPad > On Oct 3, 2019, at 12:14 PM, Stephen Satchell wrote: > > On 10/3/19 8:42 AM, Fred Baker wrote: >> >> On Oct 3, 2019, at 9:51 AM, Stephen Satchell wrote: >>> >>> Someone else mentioned that "IPv6 has been around for 25 years, and why >>> is it taking so long for ev

Re: Update to BCP-38?

On 10/3/19 8:22 AM, Fred Baker wrote: > Speaking as v6ops chair and the editor of record for 1812. > draft-ietf-v6ops-ipv6rtr-reqs kind of fell apart; it was intended to be > an 1812-like document and adopted as such, but many of the > "requirements" that came out of it were specific to the author'

Re: Update to BCP-38?

On 10/3/19 8:42 AM, Fred Baker wrote: > > >> On Oct 3, 2019, at 9:51 AM, Stephen Satchell wrote: >> >> Someone else mentioned that "IPv6 has been around for 25 years, and why >> is it taking so long for everyone to adopt it?" I present as evidence >> the lack of a formally-released requirements

Re: Update to BCP-38?

> On Oct 3, 2019, at 9:51 AM, Stephen Satchell wrote: > > Someone else mentioned that "IPv6 has been around for 25 years, and why > is it taking so long for everyone to adopt it?" I present as evidence > the lack of a formally-released requirements RFC for IPv6. It suggests > that the "scien

Re: Update to BCP-38?

On Oct 3, 2019, at 9:51 AM, Stephen Satchell wrote: > It appears that the only parallel paper for IPv6 is > draft-ietf-v6ops-ipv6rtr-reqs-04, _Requirements for IPv6 Routers_, which > currently carries a copyright of 2018. It's a shame that this document > is still in limbo; witness this quote: "

Re: Update to BCP-38?

On 03/10/2019 15:51, Stephen Satchell wrote: > For a start, *add* IPv6 examples in parallel with the IPv4 examples. 1000 times +1 We need (much) more IPv6 examples! -- Marco (pushing for IPv6 examples since 2007 or so like in: https://youtu.be/OLEizGPoB5w?t=30)

Re: Update to BCP-38?

On 10/2/19 9:51 PM, Mark Andrews wrote: > What part of BCP-38 do you think needs to be updated to support IPv6? > > Changing the examples to use IPv6 documentation prefixes instead of IPv4 > documentation prefixes? For a start, *add* IPv6 examples in parallel with the IPv4 examples. As RFCs are

Re: Update to BCP-38?

What part of BCP-38 do you think needs to be updated to support IPv6? Changing the examples to use IPv6 documentation prefixes instead of IPv4 documentation prefixes? Mark > On 3 Oct 2019, at 1:20 pm, Stephen Satchell wrote: > > Is anyone working on an update to include IPv6? -- Mark Andrews

Re: UPDATE: Anyone shed light on Verizon blocking pop3 offnetwork?

Okay. This appears to be Network based filters. We cannot connect from networks in 104/8, 158/8, or 107/8. We are able to connect using the provider IP Address on the border routers. We also had an upstream test from 199/8 and they were successful. I've already sent emails to the whois contac

Re: update

On 09/29/2014 01:14 AM, Larry Sheldon wrote: > On 9/29/2014 00:32, Pete Carah wrote: >> For that matter, has the*specification* of tcp/ip been proven to be >> "correct" in any complete way? > > I find that question in this forum really confusing. I was adding it to Valdis's statement about proven

Re: update

On Sun, 28 Sep 2014 13:22:57 -0400, Jay Ashworth said: > "The Internet is the only endeavour of man in which a single-character > typographical error in a file on a computer on the other side of the > planet *which you do not even know exists* can take your entire business > off line for the better

Re: update

On September 28, 2014 at 13:22 j...@baylink.com (Jay Ashworth) wrote: > > "The Internet is the only endeavour of man in which a single-character > typographical error in a file on a computer on the other side of the > planet *which you do not even know exists* can take your entire business

Re: update

Heh….this reminded me of a project I had to do circa 1991/2 when getting my Master's in EE where we used this book and mechanism to 'validate' TCP. http://spinroot.com/gerard/popd.html Although as a student homework assignment I wouldn't say what we did was in any way rigorous but certainly had

Re: update

On Mon, 29 Sep 2014 00:32:49 -0500, Pete Carah said: > The halting problem comes up in connection with _data_ handling in any > computer with even a language interpreter (e.g. is browser-based > javascript complete enough for the halting problem to apply to it? The halting problem applies to *any

Re: update

On 09/28/2014 11:14 PM, Larry Sheldon wrote: > I thought all of the RFC-descriptions of protocols were taken to be > statements that "if you do it this way, we think we can inter-operate" > but at no time to be taken as "right" or "wrong". Correct. That gave birth to the original "interop" confer

Re: update

for two asynchronous, otherwise unconnected systems, using TCP/IP there is a state transition sequence which can be shown to work if you stick to it. There are also (I believe) corner cases when you send unexpected sequences, and some of them have known behaviours in that sense, the question: "doe

Re: update

On 9/29/2014 00:32, Pete Carah wrote: For that matter, has the*specification* of tcp/ip been proven to be "correct" in any complete way? I find that question in this forum really confusing. I thought all of the RFC-descriptions of protocols were taken to be statements that "if you do it this

Re: update

On 09/28/2014 04:50 PM, valdis.kletni...@vt.edu wrote: > On Sun, 28 Sep 2014 15:06:18 -0600, "Keith Medcalf" said: > >> >> Sorry to disappoint, but those are not changes that make the system more >> vulnerable. They are externalities that may change the likelihood of >> exploitation of an existing

Re: update

On Sun, 28 Sep 2014 15:06:18 -0600, "Keith Medcalf" said: > >Hopefully, Keith will admit that *THAT* qualifies as a "change" in his > >book as well. If attackers are coming at you with an updated copy > >of Metasploit, things have changed > > Sorry to disappoint, but those are not changes tha

Re: update

- Original Message - > From: "Valdis Kletnieks" > On Sun, 28 Sep 2014 02:39:15 -0400, William Herrin said: > > > The vulnerabilities were there the whole time, but the progression of > > discovery and dissemination of knowledge about those vulnerabilities > > makes the systems more vulne

RE: update

On Sunday, 28 September, 2014 14:47, valdis.kletni...@vt.edu said: >On Sun, 28 Sep 2014 02:39:15 -0400, William Herrin said: >> The vulnerabilities were there the whole time, but the progression of >> discovery and dissemination of knowledge about those vulnerabilities >> makes the systems more

Re: update

On Sat, 27 Sep 2014 22:50:31 -0600, "Keith Medcalf" said: > If you had been rational about the change to from x86 -> x64 and 32-bit > userland to 64-bit userland, you would have limited all processes to the same > per-process address space as they had in the x86 model in order to prevent the > intr

Re: update

On Sun, 28 Sep 2014 02:39:15 -0400, William Herrin said: > The vulnerabilities were there the whole time, but the progression of > discovery and dissemination of knowledge about those vulnerabilities > makes the systems more vulnerable. The systems are more vulnerable > because the rest of the wor

Re: update

- Original Message - > From: "Keith Medcalf" > >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of > >valdis.kletni...@vt.edu > >On Sat, 27 Sep 2014 21:10:28 -0400, Jay Ashworth said: > > > >> I haven't an example case, but it is theoretically possible. > > > >The sendmail setuid

Re: update

- Original Message - > From: "Keith Medcalf" > >The problem is, before it is an entirely correct statement to assert > >that a zero entropy system never develops new vulnerabilities, you > >have to expand the boundaries of the "system" to include the entire > >planet. > > Incorrect. The

Re: update

> My original proposition still holds perfectly: > > (1) The vulnerability profile of a system is fixed at system commissioning. > (2) Vulnerabilities do not get created nor destroyed except through > implementation of change. > (3) If there is no change to a system, then there can be no change in

RE: update

On Sunday, 28 September, 2014 06:39, Jimmy Hess said: >On Sat, Sep 27, 2014 at 11:57 PM, Keith Medcalf >wrote:> This is another case where a change was made. >> If the change had not been made (implement the new kernel) then the >vulnerability would not have been introduced. >> The more exampl

Re: update

On Sat, Sep 27, 2014 at 11:57 PM, Keith Medcalf wrote:> This is another case where a change was made. > If the change had not been made (implement the new kernel) then the > vulnerability would not have been introduced. >[...] > The more examples people think they find, the more it proves my prop

RE: update

On Sunday, 28 September, 2014 00:39, William Herrin said: >On Fri, Sep 26, 2014 at 11:11 PM, Keith Medcalf >wrote: >> On Friday, 26 September, 2014 08:37,Jim Gettys >>said: >>>http://cyber.law.harvard.edu/events/luncheon/2014/06/gettys >> ""Familiarity Breeds Contempt: The Honeymoon Effect and

RE: update

On Saturday, 27 September, 2014 23:29, Kenneth Finnegan said: >> My original proposition still holds perfectly: >> >> (1) The vulnerability profile of a system is fixed at system >> commissioning. >> (2) Vulnerabilities do not get created nor destroyed except through >> implementation o

Re: update

On Fri, Sep 26, 2014 at 11:11 PM, Keith Medcalf wrote: > On Friday, 26 September, 2014 08:37,Jim Gettys said: >>http://cyber.law.harvard.edu/events/luncheon/2014/06/gettys > > ""Familiarity Breeds Contempt: The Honeymoon Effect and the Role of Legacy > Code in Zero-Day Vulnerabilities", by Clark

RE: update

through change. If there is no change, then the vulnerability profile is fixed. >-Original Message- >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of >valdis.kletni...@vt.edu >Sent: Saturday, 27 September, 2014 22:47 >To: Jay Ashworth >Cc: NANOG >Subject: Re: upd

RE: update

On Saturday, 27 September, 2014 20:49, Jimmy Hess said: >On Sat, Sep 27, 2014 at 8:10 PM, Jay Ashworth wrote: >> I haven't an example case, but it is theoretically possible. >Qmail-smtpd has a buffer overflow vulnerability related to integer >overflow which can only be reached when compiled on

Re: update

On Sat, 27 Sep 2014 21:10:28 -0400, Jay Ashworth said: > I haven't an example case, but it is theoretically possible. The sendmail setuid bug, where it failed to check the return code because it was *never* possible for setuid from root to non-root to fail... ... until the Linux kernel grew new f

RE: update

>> Unfortunately, that page contains near the top the ludicrous and >> impossible assertion: >> ""Familiarity Breeds Contempt: The Honeymoon Effect and the Role of >> Legacy Code in Zero-Day Vulnerabilities", by Clark, Fry, Blaze and >> Smith makes clear that ignoring these devices is foolhardy; >

Re: update

On Sat, Sep 27, 2014 at 8:10 PM, Jay Ashworth wrote: > I haven't an example case, but it is theoretically possible. Qmail-smtpd has a buffer overflow vulnerability related to integer overflow which can only be reached when compiled on a 64-bit platform. x86_64 did not exist when the code was or

Re: update

- Original Message - > From: "Keith Medcalf" > Unfortunately, that page contains near the top the ludicrous and > impossible assertion: > > ""Familiarity Breeds Contempt: The Honeymoon Effect and the Role of > Legacy Code in Zero-Day Vulnerabilities", by Clark, Fry, Blaze and > Smith mak

RE: update

On Friday, 26 September, 2014 08:37,Jim Gettys said: >For those of you who want to understand more about the situation we're >all in, go look at my talk at the Berkman Center, and read the articles >linked from there by Bruce Schneier and Dan Geer. >http://cyber.law.harvard.edu/events/luncheon/

Re: update

fsf put out a statement https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http:/

Re: update

;> From: Jared Mauch >> To: Randy Bush >> Cc: North American Network Operators' Group >> Subject: Re: update >> X-Mailer: Apple Mail (2.1985.4) >> >> Can I presume you’re talking about the bash CVE-2014-6271? >> > > Date: Wed, 24 Sep

Re: update

rom: Jared Mauch To: Randy Bush Cc: North American Network Operators' Group Subject: Re: update X-Mailer: Apple Mail (2.1985.4) Can I presume you’re talking about the bash CVE-2014-6271? Date: Wed, 24 Sep 2014 13:09:19 -0600 From: Spencer Gaw To: Randy Bush , North American Network O

Re: update

On Thu, Sep 25, 2014 at 05:11:22AM +0200, Mikael Abrahamsson wrote: > On Wed, 24 Sep 2014, Jim Popovitch wrote: > > > I *did* read that, and it doesn't change anything about what I wrote. > > Debian didn't make those changes for you.. Debian has never set > > root's shell to bash, ever. PE

Re: update

--As of September 25, 2014 4:05:16 AM +0900, Randy Bush is alleged to have said: there is an update out you want. badly. debian/ubuntu admins may want to apt-get update/upgrade or whatever freebsd similarly can not speak for other systems --As for the rest, it is mine. FreeBSD (and other BS

Re: update

> Keeping silent after the embargo is over isn't doing anyone any > favors. when do you think the embargo is over? yes, it got blabbed. but that does not mean one should be a blabber. randy

Re: update

On Wed, Sep 24, 2014 at 10:03 PM, William Herrin wrote: >> lrwxrwxrwx 1 root root 4 2014-02-22 11:52 /bin/sh -> bash > > ROFL. Jimmy, please tell me you had to start up a VM to check that. :) Not a live system, but aside from honeypots, there really are embedded appliances and companies with w

Re: update

On Sep 24, 2014 10:56 PM, "William Herrin" wrote: > > On Wed, Sep 24, 2014 at 10:52 PM, Jim Popovitch wrote: > > I *did* read that, and it doesn't change anything about what I wrote. > > Debian didn't make those changes for you.. Debian has never set > > root's shell to bash, ever. PEBKAC

Re: update

On Wed, 24 Sep 2014, Jim Popovitch wrote: I *did* read that, and it doesn't change anything about what I wrote. Debian didn't make those changes for you.. Debian has never set root's shell to bash, ever. PEBKAC? I can verify Williams settings on my Debian system that was initially inst

Re: update

On Wed, Sep 24, 2014 at 10:56 PM, Jimmy Hess wrote: > On Wed, Sep 24, 2014 at 9:43 PM, Jim Popovitch wrote: >> You have done something wrong/different than what appears on a >> relatively clean install: >> >> $ cat /etc/debian_version >> 7.6 >> $ ls -laF /bin/sh >> lrwxrwxrwx 1 root root 4 Mar 1

Re: update

On Wed, Sep 24, 2014 at 9:43 PM, Jim Popovitch wrote: > You have done something wrong/different than what appears on a > relatively clean install: > > $ cat /etc/debian_version > 7.6 > $ ls -laF /bin/sh > lrwxrwxrwx 1 root root 4 Mar 1 2012 /bin/sh -> dash* What is this fabled 7.6 that you spea

Re: update

On Wed, Sep 24, 2014 at 10:52 PM, Jim Popovitch wrote: > I *did* read that, and it doesn't change anything about what I wrote. > Debian didn't make those changes for you.. Debian has never set > root's shell to bash, ever. PEBKAC? I've been running Debian for longer than the dash shell ha

Re: update

On Wed, Sep 24, 2014 at 10:49 PM, William Herrin wrote: > On Wed, Sep 24, 2014 at 10:43 PM, Jim Popovitch wrote: >> You have done something wrong/different than what appears on a >> relatively clean install: > > Since you didn't read it, I'm gonna repeat it: > > "If you installed Debian from scra

Re: update

On Wed, Sep 24, 2014 at 10:43 PM, Jim Popovitch wrote: > You have done something wrong/different than what appears on a > relatively clean install: Since you didn't read it, I'm gonna repeat it: "If you installed Debian from scratch in the last couple of years you might have gotten a different s

Re: update

On Wed, Sep 24, 2014 at 10:29 PM, William Herrin wrote: > On Wed, Sep 24, 2014 at 7:36 PM, Daniel Jackson wrote: >> On 09/24/2014 07:22 PM, Jim Popovitch wrote: >>> That won't automatically invoke bash on Debian/Ubuntuunless someone >>> intentionally changed default shells >> >> People se

Re: update

On Wed, Sep 24, 2014 at 7:36 PM, Daniel Jackson wrote: > On 09/24/2014 07:22 PM, Jim Popovitch wrote: >> That won't automatically invoke bash on Debian/Ubuntuunless someone >> intentionally changed default shells > > People seem not to know that Debian and derivatives use a variant Almquis

Re: update

On Wed, Sep 24, 2014 at 7:41 PM, Chris Adams wrote: > Has anybody looked to see if the popular web software the users install > and don't maintain (e.g. Wordpress, phpBB, Joomla, Drupal) use system() Wouldn't it be great if it was JUST system()? It's also popen(), shell_exec(), passhru(), e

Re: update

Once upon a time, Daniel Jackson said: > On 09/24/2014 07:22 PM, Jim Popovitch wrote: > >That won't automatically invoke bash on Debian/Ubuntuunless someone > >intentionally changed default shells > > People seem not to know that Debian and derivatives use a variant > Almquist shell rathe

Re: update

On 09/24/2014 07:22 PM, Jim Popovitch wrote: That won't automatically invoke bash on Debian/Ubuntuunless someone intentionally changed default shells -Jim P. People seem not to know that Debian and derivatives use a variant Almquist shell rather than bash for system accounts. Daniel

Re: update

On Sep 24, 2014 7:00 PM, wrote: > > On Wed, 24 Sep 2014 18:50:05 -0400, Jim Popovitch said: > > > If someone is already invoking #!/bin/bash from a cgi, then they are > > already doing it wrong (bash has massive bloat/overhead for a CGI script). > > You sure you don't have *any* cgi's that do some

Re: update

On Wed, 24 Sep 2014 18:50:05 -0400, Jim Popovitch said: > If someone is already invoking #!/bin/bash from a cgi, then they are > already doing it wrong (bash has massive bloat/overhead for a CGI script). You sure you don't have *any* cgi's that do something like system("mail -s 'cgi program xxyz

Re: update

On 09/24/14 18:50, Jim Popovitch wrote: > On Sep 24, 2014 6:39 PM, "Michael Thomas" wrote: >> >> On 9/24/14, 3:27 PM, Jim Popovitch wrote: >>> On Wed, Sep 24, 2014 at 6:17 PM, Brandon Whaley > wrote: The scope of the issue isn't limited to SSH, that's just a popular example people are u

Re: update

On Sep 24, 2014 6:39 PM, "Michael Thomas" wrote: > > > On 9/24/14, 3:27 PM, Jim Popovitch wrote: >> >> On Wed, Sep 24, 2014 at 6:17 PM, Brandon Whaley wrote: >>> >>> The scope of the issue isn't limited to SSH, that's just a popular >>> example people are using. Any program calling bash could po

Re: update

On 9/24/14, 3:27 PM, Jim Popovitch wrote: On Wed, Sep 24, 2014 at 6:17 PM, Brandon Whaley wrote: The scope of the issue isn't limited to SSH, that's just a popular example people are using. Any program calling bash could potentially be vulnerable. Agreed. My point was that bash is not all t

Re: update

On Wed, Sep 24, 2014 at 6:17 PM, Brandon Whaley wrote: > The scope of the issue isn't limited to SSH, that's just a popular > example people are using. Any program calling bash could potentially > be vulnerable. Agreed. My point was that bash is not all that popular on debian/ubuntu for account

Re: update

The scope of the issue isn't limited to SSH, that's just a popular example people are using. Any program calling bash could potentially be vulnerable. On Wed, Sep 24, 2014 at 6:11 PM, Jim Popovitch wrote: >> debian/ubuntu admins may want to apt-get update/upgrade or whatever > > debian/ubuntu ar

Re: update

> debian/ubuntu admins may want to apt-get update/upgrade or whatever debian/ubuntu aren't really all that immediately impacted. $ grep "bash$" /etc/passwd | wc -l 2 ^^ both of those are user accounts, not system/daemon accounts. -Jim P.

Re: update

Keeping silent after the embargo is over isn't doing anyone any favors. I think Florian said it best in his most recent message: "In this particular case, I think we had to publish technical details so that those who cannot patch immediately can at least try to mitigate this vulnerability usin

Re: update

See: http://seclists.org/oss-sec/2014/q3/650 Regards, SG On 9/24/2014 1:05 PM, Randy Bush wrote: there is an update out you want. badly. debian/ubuntu admins may want to apt-get update/upgrade or whatever freebsd similarly can not speak for other systems

Re: update

> See: http://seclists.org/oss-sec/2014/q3/650 sigh. i am well aware of it but saw no benefit for further blabbing a vuln randy

Re: update

Can I presume you’re talking about the bash CVE-2014-6271? - jared > On Sep 24, 2014, at 3:05 PM, Randy Bush wrote: > > there is an update out you want. badly. > debian/ubuntu admins may want to apt-get update/upgrade or whatever > freebsd similarly > can not speak for other systems

  1   2   >