from:"Giancarlo Razzolini"

Hi,

I was configuring one new interface in one of my new machines, and I
disabled ipv6 with -inet6 as I always do. But I handcrafted the
hostname.if file and forgot to put a NONE in the broadcast address. This
caused the ifconfig to segfault when called from the /etc/netstart
script. For example:

/etc/hostname.if:
inet 1.2.3.4 255.255.255.0 -inet6

result: ifconfig segfault.

/etc/hostname.if:
inet 1.2.4.5 255.255.255.0 NONE -inet6

result: everything work as usual.

   I am using 5.5 stable. Can't post the dmesg right now, but will
do this night. I will also take a look at the core dump, see if I can
pinpoint where are the bits responsible for the segfault.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

Em 16-05-2014 16:45, Kenneth Westerback escreveu:
 On 16 May 2014 15:00, Giancarlo Razzolini grazzol...@gmail.com wrote:
 Hi,

 I was configuring one new interface in one of my new machines, and I
 disabled ipv6 with -inet6 as I always do. But I handcrafted the
 hostname.if file and forgot to put a NONE in the broadcast address. This
 caused the ifconfig to segfault when called from the /etc/netstart
 script. For example:

 /etc/hostname.if:
 inet 1.2.3.4 255.255.255.0 -inet6

 result: ifconfig segfault.

 /etc/hostname.if:
 inet 1.2.4.5 255.255.255.0 NONE -inet6

 result: everything work as usual.

I am using 5.5 stable. Can't post the dmesg right now, but will
 do this night. I will also take a look at the core dump, see if I can
 pinpoint where are the bits responsible for the segfault.

 Cheers,

 --
 Giancarlo Razzolini
 GPG: 4096R/77B981BC

 Did a quick test on amd64 -current using run0, and got 'bad value: -inet6'.

  Ken
As I mentioned, I'm running 5.5 stable. So this might got fixed in
current, I'm taking a look at the CVS commits right now to see if it was
fixed. But, funny thing, I've managed to get another segmentation fault,
this time from command line. While trying to replicate the bug in
another machine, I've wrongly typed:

ifconfig em4 -inet

Instead of:

ifconfig em4 -inet6

The first command also caused a segfault. As promised, follows a dmesg
of one of the machines where I reproduced this segfault:

OpenBSD 5.5 (GENERIC) #0: Fri Apr 25 13:07:59 CEST 2014
   
r...@stable-55-amd64.mtier.org:/binpatchng/work-binpatch55-amd64/src/sys/arch/amd64/compile/GENERIC
real mem = 520085504 (495MB)
avail mem = 497729536 (474MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf09f0 (10 entries)
bios0: vendor Bochs version Bochs date 01/01/2011
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
mpbios at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: QEMU Virtual CPU version 2.0.0, 2813.47 MHz
cpu0:
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,POPCNT,NXE,LONG,LAHF,SVM,ABM,SSE4A
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02
pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00
pciide0 at pci0 dev 1 function 1 Intel 82371SB IDE rev 0x00: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: QEMU HARDDISK
wd0: 16-sector PIO, LBA48, 30720MB, 62914560 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 2.0. ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 Intel 82371SB USB rev 0x01: irq 11
piixpm0 at pci0 dev 1 function 3 Intel 82371AB Power rev 0x03: irq 9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 Cirrus Logic CL-GD5446 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00:
Virtio Network Device
vio0 at virtio0: address 52:54:00:ab:f7:d6
virtio0: irq 11
virtio1 at pci0 dev 4 function 0 Qumranet Virtio Memory rev 0x00:
Virtio Memory Balloon Device
viomb0 at virtio1
virtio1: irq 11
virtio2 at pci0 dev 5 function 0 Qumranet Virtio Network rev 0x00:
Virtio Network Device
vio1 at virtio2: address 52:54:00:4f:65:af
virtio2: irq 10
virtio3 at pci0 dev 6 function 0 Qumranet Virtio Network rev 0x00:
Virtio Network Device
vio2 at virtio3: address 52:54:00:42:d8:ff
virtio3: irq 10
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 1: density unknown
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1
nvram: invalid checksum
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (ae6577d8240a3c26.a) swap on wd0b dump on wd0b
clock: unknown CMOS layout

This one is my test machine, and yes, it's virtualized

Re: ifconfig segmentation fault

Em 16-05-2014 17:18, Stuart Henderson escreveu:
 On 2014/05/16 17:12, Giancarlo Razzolini wrote:
 As I mentioned, I'm running 5.5 stable. So this might got fixed in
 current, I'm taking a look at the CVS commits right now to see if it was
 fixed. But, funny thing, I've managed to get another segmentation fault,
 this time from command line. While trying to replicate the bug in
 another machine, I've wrongly typed:

 ifconfig em4 -inet

 Instead of:

 ifconfig em4 -inet6
 I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb?
 i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run',
 then if you can trigger it do a 'bt'.

Yes, I was able to repeat:

(gdb) set args em4 -inet
(gdb) run
Starting program: /sbin/ifconfig em4 -inet
warning: shared library handler failed to enable breakpoint

Program received signal SIGSEGV, Segmentation fault.
0x0043607a in ?? ()
(gdb) bt
#0  0x0043607a in ?? ()
#1  0x00412835 in ?? ()
#2  0x00412ac5 in ?? ()
#3  0x00404919 in ?? ()
#4  0x0040aaba in ?? ()
#5  0x00400301 in ?? ()
#6  0x0003 in ?? ()
#7  0x7f7beb28 in ?? ()
#8  0x7f7beb37 in ?? ()
#9  0x7f7beb3b in ?? ()
#10 0x in ?? ()

Very odd. If you want I can also attach the core dump.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

Em 16-05-2014 17:18, Stuart Henderson escreveu:
 On 2014/05/16 17:12, Giancarlo Razzolini wrote:
 As I mentioned, I'm running 5.5 stable. So this might got fixed in
 current, I'm taking a look at the CVS commits right now to see if it was
 fixed. But, funny thing, I've managed to get another segmentation fault,
 this time from command line. While trying to replicate the bug in
 another machine, I've wrongly typed:

 ifconfig em4 -inet

 Instead of:

 ifconfig em4 -inet6
 I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb?
 i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run',
 then if you can trigger it do a 'bt'.

Just to be thrill, here follows my sha256sum of my /sbin/ifconfig:

SHA256 (/sbin/ifconfig) =
e1b9688f2ebf5a278408c49ac13e35479a96b883ff9891ada141470d55a1b158

If anyone running stable can check it yours is the same, I appreciate.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

Em 16-05-2014 18:15, Stuart Henderson escreveu:
 On 2014/05/16 17:26, Giancarlo Razzolini wrote:
 Em 16-05-2014 17:18, Stuart Henderson escreveu:
 On 2014/05/16 17:12, Giancarlo Razzolini wrote:
 As I mentioned, I'm running 5.5 stable. So this might got fixed in
 current, I'm taking a look at the CVS commits right now to see if it was
 fixed. But, funny thing, I've managed to get another segmentation fault,
 this time from command line. While trying to replicate the bug in
 another machine, I've wrongly typed:

 ifconfig em4 -inet

 Instead of:

 ifconfig em4 -inet6
 I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb?
 i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run',
 then if you can trigger it do a 'bt'.

 Yes, I was able to repeat:

 (gdb) set args em4 -inet
 (gdb) run
 Starting program: /sbin/ifconfig em4 -inet
 warning: shared library handler failed to enable breakpoint

 Program received signal SIGSEGV, Segmentation fault.
 0x0043607a in ?? ()
 (gdb) bt
 #0  0x0043607a in ?? ()
 #1  0x00412835 in ?? ()
 #2  0x00412ac5 in ?? ()
 #3  0x00404919 in ?? ()
 #4  0x0040aaba in ?? ()
 #5  0x00400301 in ?? ()
 #6  0x0003 in ?? ()
 #7  0x7f7beb28 in ?? ()
 #8  0x7f7beb37 in ?? ()
 #9  0x7f7beb3b in ?? ()
 #10 0x in ?? ()

 Very odd. If you want I can also attach the core dump.

 Cheers,

 -- 
 Giancarlo Razzolini
 GPG: 4096R/77B981BC

 Oh, static stripped binary of course... worth a try with this,
 if you have 5.5-stable sources on the system:

 cd /usr/src/sbin/ifconfig
 make obj
 make clean
 make DEBUG=-g -O0
 gdb obj/ifconfig
 [...]

In this system I don't. But will do ASAP. I'm starting to believe that
this has something to do with virtualization.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

Em 16-05-2014 18:19, Héctor Luis Gimbatti escreveu:
 /etc/hostname.if
 Inet 1.2.3.4 255.255.255.0 NONE -inet6

 # ksh /etc/netstart
 # ifconfig 
 ## NO PROBLEM

 /etc/hostname.if
 Inet 1.2.3.4 255.255.255.0 -inet6

 # ksh /etc/netstart
 ifconfig: -inet6: bad value
 ## NO SEGMENTATION FAULT


 So, IMHO, if there is any problem at all, of course it should be due to the 
 ''correctness'' of the line in /etc/hostname.
 We should check if the parsing of such file is OK (by that I mean of course 
 to check for the correctness of the values )

 But AFAIK , and As Far I've tested /etc/hostname.if for different, WRONG 
 LINES, it has never cause ifconfig to segfault.




Anyone else running OpenBSD under linux kvm can test this? I was only
able to reproduce it on virtualized machines. My test on a physical one
wasn't on 5.5 and it didn't segfault, as I wrongly stated before. I was
so eager to test it, that I wasn't logged on the right machine, sorry.
Stuart, I didn't had a chance yet to recompile ifconfig following your
instructions, but I'll try to ASAP. Really seem to be something with
virtualization itself. I've tried on three OpenBSD installs that are
under kvm, and all of them segfaulted. All of them are amd64, I didn't
tried with an i386 installation.


Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

Em 16-05-2014 23:48, sven falempin escreveu:



 On Fri, May 16, 2014 at 10:15 PM, Giancarlo Razzolini
 grazzol...@gmail.com mailto:grazzol...@gmail.com wrote:

 Em 16-05-2014 18:19, Héctor Luis Gimbatti escreveu:
  /etc/hostname.if
  Inet 1.2.3.4 255.255.255.0 NONE -inet6
 
  # ksh /etc/netstart
  # ifconfig
  ## NO PROBLEM
 
  /etc/hostname.if
  Inet 1.2.3.4 255.255.255.0 -inet6
 
  # ksh /etc/netstart
  ifconfig: -inet6: bad value
  ## NO SEGMENTATION FAULT
 
 
  So, IMHO, if there is any problem at all, of course it should be
 due to the ''correctness'' of the line in /etc/hostname.
  We should check if the parsing of such file is OK (by that I
 mean of course to check for the correctness of the values )
 
  But AFAIK , and As Far I've tested /etc/hostname.if for
 different, WRONG LINES, it has never cause ifconfig to segfault.
 
 
 
 
 Anyone else running OpenBSD under linux kvm can test this? I was only
 able to reproduce it on virtualized machines. My test on a
 physical one
 wasn't on 5.5 and it didn't segfault, as I wrongly stated before.
 I was
 so eager to test it, that I wasn't logged on the right machine, sorry.
 Stuart, I didn't had a chance yet to recompile ifconfig following your
 instructions, but I'll try to ASAP. Really seem to be something with
 virtualization itself. I've tried on three OpenBSD installs that are
 under kvm, and all of them segfaulted. All of them are amd64, I didn't
 tried with an i386 installation.


 Cheers,

 --
 Giancarlo Razzolini
 GPG: 4096R/77B981BC


 Linux / kvm is not a precise statement enough,

 for example on recent version the network can completly stop under
 load (but is very fast) while older release remain stable.

 What qemu version ? what (linux)kernel version ?


 -- 
 -
 () ascii ribbon campaign - against html e-mail 
 /\ 
It's a ubuntu 14.04 running kernel 3.13.0 and the qemu-kvm version is
2.0.0. I believe that on Monday I'll be able to test it more and even
compile ifconfig, as Stuart mentioned. Just to be clear, my machines
work perfectly I don't have any problems at all.


Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

2014-05-19 Thread Giancarlo Razzolini

Em 16-05-2014 18:15, Stuart Henderson escreveu:
 Oh, static stripped binary of course... worth a try with this,
 if you have 5.5-stable sources on the system:

 cd /usr/src/sbin/ifconfig
 make obj
 make clean
 make DEBUG=-g -O0
 gdb obj/ifconfig
 [...]
Stuart,

Today I was able to debug it and here is the result. I hope it
helps. I'm posting it right now, and looking into the lines that trigger
the segfault, hopefully you'll be able to look into it too. As I
mentioned before, this isn't impeding me from using the virtualized
machines at all, it was just something I stumbled upon by accident when
I forgot to put the NONE in the hostname.if file. But, if this leads to
fixing a bug, it would be nice. Follow:

(gdb) set args em4 -inet
(gdb) run
Starting program: /usr/obj/sbin/ifconfig/ifconfig em4 -inet

Program received signal SIGSEGV, Segmentation fault.
strlcpy (dst=0x84e658 , src=0x0, siz=Variable siz is not available.
) at /usr/src/lib/libc/string/strlcpy.c:37
37  if ((*d++ = *s++) == '\0')
(gdb) bt
#0  strlcpy (dst=0x84e658 , src=0x0, siz=Variable siz is not available.
) at /usr/src/lib/libc/string/strlcpy.c:37
#1  0x004139a5 in _fillhostent (h=0x20ab94000, r=0x84e620,
buf=Variable buf is not available.
) at /usr/src/lib/libc/asr/gethostnamadr.c:72
#2  0x00413c35 in gethostbyname2 (name=Variable name is not
available.
) at /usr/src/lib/libc/asr/gethostnamadr.c:124
#3  0x0040ad63 in in_getaddr (s=0x7f7ea9ac -inet, which=1)
at /usr/src/sbin/ifconfig/ifconfig.c:4524
#4  0x00401968 in setifaddr (addr=0x7f7ea9ac -inet,
param=0) at /usr/src/sbin/ifconfig/ifconfig.c:1112
#5  0x00400afd in main (argc=1, argv=0x7f7ea890) at
/usr/src/sbin/ifconfig/ifconfig.c:738

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: new OpenSSL flaws

Em 05-06-2014 15:42, dera...@cvs.openbsd.org escreveu:
 We are sorry that the errata for these libssl security issues are not
 up yet.

 The majority of these issues are in our ssl library as well.

 Most other operating system vendors have patches available, but that
 is because they were (obviously) given a heads up to prepare them over
 the last few days.

 OpenBSD / LibreSSL did not receive any heads-up from OpenSSL.



 So hold on, we'll try to have errata out in a few hours.

Theo,

I'm just curious, but, this happened in the past?

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: new OpenSSL flaws

Em 05-06-2014 15:57, Theo de Raadt escreveu:
 Em 05-06-2014 15:42, dera...@cvs.openbsd.org escreveu:
 We are sorry that the errata for these libssl security issues are not
 up yet.

 The majority of these issues are in our ssl library as well.

 Most other operating system vendors have patches available, but that
 is because they were (obviously) given a heads up to prepare them over
 the last few days.

 OpenBSD / LibreSSL did not receive any heads-up from OpenSSL.



 So hold on, we'll try to have errata out in a few hours.

 Theo,

 I'm just curious, but, this happened in the past?
 Sure, it has happened in the past.  But probably not to this
 degree.

 Some sort of timeline has been published.  Read between the lines.

 http://seclists.org/oss-sec/2014/q2/466
Hmmm, the first thing I did on that page was ctrl + f OpenBSD: not
found. It's very interesting that this happened, to this degree as you
mentioned, just after you guys forked OpenSSL. I've disable most of the
daemons that use ssl in my systems, until this errata comes along. Don't
hush it, specially since you guys didn't got notified of this.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: new OpenSSL flaws

Em 05-06-2014 16:27, Theo de Raadt escreveu:
 There are two main open-source processes for dealing with discovery of
 security issues and disclosure of that information to the greater
 community.

 - One common process is that generally followed by OpenBSD.  In this
   proocess a bug is found, and a fix is commited as soon as the
   improvement is known to good.  Then if an asssement has been done, and
   it is determined to be important, disclosure occurs, of course after
   the commit is already public.  Everyone including the vendors had the
   opportunity to get the information in a fair and equal way.

 - The other main process used by some open source groups, is to
   quarantine important repairs.  A fix is firsst disclosed all affected
   parties, or at least the right concerned subset.  This creates a delay
   before information availability, but the coordination is intended to
   provide a benefit.  Everyone generally gets the information in a fair
   and equal way.

 Both processses have their place.  Each software group has their own
 limitations and needs which will drive their selection.


 Is clear that the second process -- intending to also take an ethical
 path for disclosure -- should not specifically exclude a part of the
 community.


 Unfortunately I find myself believing reports that the OpenSSL people
 intentionally asked others for quarantine, and went out of their way
 to ensure this information would not come to OpenBSD and LibreSSL.

 There, I've said it.
That's exactly my though. Specially, because FreeBSD and NetBSD were
warned, but not OpenBSD. If this was only a rant or any childish
behavior from them, it's something stupid and, of course, not the right
thing to do. But hey, we're all human. My real concern is if this
something else, a hidden agenda, in that this stupid disclosure was
indeed, carefully planed. One can never have too many conspiracy
theories. Specially after what has been happening the last year. Thanks
for the clarification.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: new OpenSSL flaws

Em 05-06-2014 19:43, Bob Beck escreveu:
 For the record, we didn't get advance notice of Heartbleed either, so
 this is nothing new.
Bob,

I didn't knew that. I feel like I've released a monster (Cthulhu
anyone?). I was just curious when I asked Theo if this did happened
before. It's possible that someone else would also ask him that. Anyway,
this kind of thing hurts the entire FLOSS movement. The whole point of
writing a open source project is collaboration. It seems that OpenSSL
took a step backward on this. Now, I wonder, if there won't be LibreSSL
code appearing on OpenSSL.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Patch: ifconfig - fix SIGSEGV

2014-06-06 Thread Giancarlo Razzolini

Em 06-06-2014 03:49, Fabian Raetz escreveu:
 On Thu, Jun 05, 2014 at 07:39:01PM +0200, Fabian Raetz wrote:
 Hi tech@,
 Please ignore this thread!

 A reboot after rebuilding userland fixed the problem. Sorry!

 when calling ifconfig(8) with a not supported option like below, it
 segfaults.

  ifconfig [interface] -someParameterNotSupportedWithALeadingMinus
  ifconfig re0 -adaw
  ifconfig iwn0 -media


 Here's a backtrace:

 #0  strlcpy (dst=0x84c658 _entbuf+24 , src=0x0, siz=optimized out) at 
 /usr/src/lib/libc/string/strlcpy.c:37
 #1  0x00413a45 in _fillhostent (h=0x200f7f800, r=0x84c620 
 _hostent, buf=optimized out, len=4096) at 
 /usr/src/lib/libc/asr/gethostnamadr.c:73
 #2  0x00413ceb in _gethostbyname (h_errnop=optimized out, 
 buflen=optimized out, buf=optimized out, ret=optimized out, 
 af=optimized out, 
 name=optimized out) at /usr/src/lib/libc/asr/gethostnamadr.c:125
 #3  gethostbyname2 (name=optimized out, af=2) at 
 /usr/src/lib/libc/asr/gethostnamadr.c:152
 #4  0x0040ae78 in in_getaddr (s=0x7f7d6f93 -asdf, which=1) at 
 /usr/src/sbin/ifconfig/ifconfig.c:4556
 #5  0x004019b4 in setifaddr (addr=0x7f7d6f93 -asdf, param=0) 
 at /usr/src/sbin/ifconfig/ifconfig.c:1112
 #6  0x00400b01 in main (argc=1, argv=0x7f7d6d78) at 
 /usr/src/sbin/ifconfig/ifconfig.c:738



 And here a patch that fixes the problem for me. Hope this is the right
 place to errx().


 Another thing i observed is that when calling ifconfig re0 awdawd
 it behaves like calling ifconfig re0 up but i have not looked into
 this.

 Tested against -current amd64

 Regards,
 Fabian


 Index: ifconfig.c
 ===
 RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
 retrieving revision 1.283
 diff -u -p -r1.283 ifconfig.c
 --- ifconfig.c   12 May 2014 08:47:37 -  1.283
 +++ ifconfig.c   5 Jun 2014 17:17:17 -
 @@ -4552,14 +4552,15 @@ in_getaddr(const char *s, int which)
  errx(1, %d: bad prefixlen, bits);
  in_getprefix(p, MASK);
  memcpy(sin-sin_addr, tsin.sin_addr, sizeof(sin-sin_addr));
 -} else if (inet_aton(s, sin-sin_addr) == 0) {
 +} else if (inet_aton(s, sin-sin_addr) == 1) {
  if ((hp = gethostbyname(s)))
  memcpy(sin-sin_addr, hp-h_addr, hp-h_length);
  else if ((np = getnetbyname(s)))
  sin-sin_addr = inet_makeaddr(np-n_net, INADDR_ANY);
  else
  errx(1, %s: bad value, s);
 -}
 +} else
 +errx(1, %s: bad value, s);
  }
  
  /* ARGSUSED */
Fabian,

Is your machine running under qemu/kvm? If so, you might had came
across the same issue I had:

http://marc.info/?l=openbsd-techm=140026687510910w=2

It's nice to know that the latest snapshot solves this issue. I'll
give it a try.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: new OpenSSL flaws

2014-06-07 Thread Giancarlo Razzolini

Em 07-06-2014 00:04, Solar Designer escreveu:
 tools and ethics are separate things
It seems like you got to the real issue now.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

ifstated(8) improvement

2014-06-09 Thread Giancarlo Razzolini

Hi tech,

I've been using ifstated for years now for failover my links and
I've developed quite some tools on top of it. But, I've recently reached
a cornerstone. I've developed a series of scripts that are called with
the run argument on the init of each state that perform a series of
tasks. One of these tasks is to write to a database (currently sqlite)
and based on the last state changes, perform different actions. But,
since I can't talk directly to the ifstated daemon, I have a delay since
I can affect any state change on it.

So, I've been planning on improving ifstated itself, for it to be
able to keep track of state changes and the time they happened, so it
can be able to improve it's decision making capabilities in the sense
that it can perform state changes based on previous states changes. Not
just on external commands results or interface statuses. You could say
something like this:

 set-state X
if ! previous_state Y

More to that, it could be also based on a more simplistic approach,
using counters. With the possibility of zeroing the counters from
ifstated.conf based on conditions. Or both, time and counters. So one
could change to a different state if one of the links is flapping
between states. I know this makes it not a pure machine state, but I
believe that the improvements can be worth the change. What you guys think?

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifstated(8) improvement

2014-06-09 Thread Giancarlo Razzolini

Em 09-06-2014 12:03, sven falempin escreveu:
 ifstated is a cool FSM emgine for handling the carp problems,
 for more complex need , instead of hacking this not complete FSM engine,
 i would just used another software.

 The last time, i just use plain perl script, because it was convenient
 and easy to read,
 using a true FSM design was just making the logic more complex.

 IMHO the way to improve ifstated is to fork it so it becomes a full FSM 
 engine,
 with transition and node definition, and each part using perl or ksh code.

 node 1 {
   entry : {perl code}
   leaving: {ksh code}
   eventX : node 2
 }

 The all work would be on the eventX , how to create one in a cron like
 process, how to bind the superb kqueue, and
 how to get notified from the network states change.

 Now , if ifstated is not able to handle what it was design for (CARP)
 i guess it should be fixed.
It definitively does what it was designed for. But I believe that these
improvements would also benefit carp only deployments. If a carp node is
failing more than N times in the last few minutes, it might be a good
idea to completely fail it over and enter on a different state. I use my
ifstated setup for both carp and isp link failure detection. I took a
look at ifstated code and I've been fiddling with it for a little time
now. I believe that the counter based approach is easy to implement with
less disruption. The time based one is more difficult. As I mentioned,
I've been using ifstated for years now (10+ IIRC). And more often than
not, isp links behave erratic. Carp can also have problems if the
network hardware underneath it does not behave correctly. I don't
believe that all of these situations can be solved even with a true FSM.
That's why I'm proposing these improvements. But, I wanted to discuss
with you guys here on tech@ first. Perhaps something entirely different
needs to be done.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifstated(8) improvement

2014-06-09 Thread Giancarlo Razzolini

Em 09-06-2014 12:25, sven falempin escreveu:
 Detecting bad network is problematic, i try to access external service for 
 this,
 dns and tcp, this can be done inside ifstated.
Do this already, in the same and different ways. It all depends on
what's available for network failure detection on the site. I always
prefer snmp for this. But there are sites where it's not possible to do so.
 For the counter, you could use a file and modified it from ifstated,
 and do a if grep 10 /my/file
 echo my file reach 10| mail -s alert root; call real action; erase file,
I use a database for this. Used files in the beginning but improved to a
database. But I need to wait a state change and/or I need to have a run
every statement that will make the decision. But, since It's only a
boolean, I need to have several run every statements to be able to
cover all cases. This makes the ifstated daemon a little slower, so the
overall link failure detection takes more time.

 but lets wait for people with more insight :-)
Yes. I'll probably hack it anyway. But if more people here on tech@
helps with suggestions/directions, I'll probably do a better job. Thanks
in advance for your time.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: signed packages

2014-01-22 Thread Giancarlo Razzolini

Em 22-01-2014 11:00, Bob Beck escreveu:
 Our lists are so full of helpful smart people who think chains of
 trust are magical pixie dust coming from root-provider-fairylands
 where the root cert faires live in castles of uncompromising fortitude
 that are never full of government plants and are whose certificates
 are magically transported into operating systems and placed in that
 special place in our hearts where no file could ever be modified...
 They also suggest we should move the machines that generate the
 releases into of those same castles where power is cheaper to save
 money...

 I think I'll make sure to advertise the next OpenBSD Foundation
 funding campaign by suggesting that you're not actually not real
 people, but a helpful-suggestions-posting-bot sponsored by the NSA..
  Or maybe it's that they've infiltrated our educational systems...
 Please get our your tinfoil hats kids.

Bob,

There were lots of e-mails through the years on misc, some of
myself, that asked for more, how can I say, trustiness on the getting
the source and/or, just using the binaries provided by OpenBSD. I
believe that signify helps a lot on this. I took a look at the code and
it's simple and beautiful.

I myself download the installXX.iso and source code from different
mirrors/anoncvs, and using different internet links, just to be sure
that things are in order. I'll be even more paranoid with the next
release to make sure I have the right keys, both for 5.5 and the ones
that follow. Tinfoil hats apart, I believe that with the interdiction
programs that NSA has, and maybe also other governments, CD's can not be
entitled with the same trust as before. I believe that DNSSEC is just
one of the many things that could be done to make this trust more easy
to obtain and verify. I've been living without it anyway.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: signed packages

2014-01-23 Thread Giancarlo Razzolini

Em 23-01-2014 09:33, Kevin Chadwick escreveu:
 Why would you have so much trust in the ether unless you have met
 someone with say a DNSSEC key or have a web of trust with someone you
 have met and that you trust and has met and swapped keys further up
 the line. The first key for DNSSEC is almost always untrusted, though
 you can use SSL to check the fingerprint. Surely it takes more
 resources for the NSA to get your particular CD? and surely you should
 be prioritising other concerns than the NSA anyway and would see the
 CD as a valuable extra authentication? Along the lines of what the
 OpenBSD manual says, if the black suits target you, do you really
 believe you can stop them? 
It is true that the first key of DNSSEC is always untrusted. But,
there are plenty more ways to check it than the number OpenBSD mirrors.
So the target is much bigger. I use every and any mean possible to
validate things, DNSSEC would make things a little simpler, just it. I
don't trust anything, not even myself. Humans have the tendency o
fucking things up. The same for compromised machines. At least I can try
to keep my machines not compromised. Unless some crazy scientist invents
an injection that cures humans from making mistakes.

I do not believe I can stop any government with loads of money from
compromising my machines. But at the very least I can try to put up a
hell of a fight for them. I do not like to be the low hanging fruit.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: signed packages

2014-01-27 Thread Giancarlo Razzolini

Em 27-01-2014 01:33, Nicolai escreveu:
 All the TLD and other massive outages say otherwise. I can think of
 one project that uses DNSSEC to verify files via TXT lookups. Their
 last DNSSEC outage? 3 days ago. Ed25519 in signify provides a 128-bit
 security level and is decentralized. DNSSEC provides 112 bits at best,
 via a government-controlled hierarchy. Nicolai 
I mentioned before that DNSSEC isn't perfect. Even IETF recognizes
this and they have indicated that they will improve the situation. When,
and how is a mystery.  The thing is, that DNSSEC adds in security. Even
with all it's problems. It would be one thing else to compromise. There
is no ultimately trust in real life, why there would be in the internet?
I wont die if they don't add it. Just will keep doing the same things
and hoping that I did not were compromised.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Patch for rc.conf(8) man page

2014-02-10 Thread Giancarlo Razzolini

As mentioned before on misc@, some user got confused and copied the
entire rc.conf file to rc.conf.local and then proceeded editing it. This
patch brings the rc.conf man page closer to the text that is in the
OpenBSD faq. Hopefully it will help newcomers avoiding this mistake.

Index: share/man/man8/rc.conf.8
===
RCS file: /cvs/src/share/man/man8/rc.conf.8,v
retrieving revision 1.20
diff -u -p -u -r1.20 rc.conf.8
--- share/man/man8/rc.conf.817 Mar 2012 14:46:40 -  1.20
+++ share/man/man8/rc.conf.810 Feb 2014 19:59:00 -
@@ -45,11 +45,13 @@ in the
 series in order to set shell variables used therein
 to control the behaviour of the scripts.
 .Pp
-It is advisable to leave
+We strongly suggest you do not alter
 .Nm rc.conf
-untouched, and instead create and edit a new
+itself. Instead create and edit a new
 .Nm rc.conf.local
-file.
+file and copy only the variables you wish to change from
+.Nm rc.conf
+and adjust them as you like.
 Variables set in this file will override variables previously set in
 .Nm rc.conf .
 .Pp

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Patch for rc.conf(8) man page

2014-02-10 Thread Giancarlo Razzolini

Em 10-02-2014 18:28, Mark Kettenis escreveu:
 Date: Mon, 10 Feb 2014 18:05:38 -0200
 From: Giancarlo Razzolini grazzol...@gmail.com

 As mentioned before on misc@, some user got confused and copied the
 entire rc.conf file to rc.conf.local and then proceeded editing it. This
 patch brings the rc.conf man page closer to the text that is in the
 OpenBSD faq. Hopefully it will help newcomers avoiding this mistake.
 I think your new text is not an improvement.

 Index: share/man/man8/rc.conf.8
 ===
 RCS file: /cvs/src/share/man/man8/rc.conf.8,v
 retrieving revision 1.20
 diff -u -p -u -r1.20 rc.conf.8
 --- share/man/man8/rc.conf.817 Mar 2012 14:46:40 -  1.20
 +++ share/man/man8/rc.conf.810 Feb 2014 19:59:00 -
 @@ -45,11 +45,13 @@ in the
  series in order to set shell variables used therein
  to control the behaviour of the scripts.
  .Pp
 -It is advisable to leave
 +We strongly suggest you do not alter
  .Nm rc.conf
 -untouched, and instead create and edit a new
 +itself. Instead create and edit a new
  .Nm rc.conf.local
 -file.
 +file and copy only the variables you wish to change from
 +.Nm rc.conf
 +and adjust them as you like.
  Variables set in this file will override variables previously set in
  .Nm rc.conf .
  .Pp

 -- 
 Giancarlo Razzolini
 GPG: 4096R/77B981BC

The text on the faq should be revised then. This patch only makes the
text on the man page closer to the faq. I believe that the man pages are
to be considered the de facto source for documentation, not the other
way around. What's your suggestion for the text?

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Patch for rc.conf(8) man page

2014-02-10 Thread Giancarlo Razzolini

Em 10-02-2014 19:34, Marco S Hyman escreveu:
 The existing text, Create and edit a _new_ rc.conf.local file seems
 fine to me - man pages are generally non-verbose - if copying was intended, 
 the manual would have said so.
 Disagree. Create and edit... is ambiguous.  I can create
 a new file by copying an old file and often do so.  If you
 want the new file start out empty then say so.

 We strongly suggest you do not alter
 .Nm rc.conf .
 Instead, create an empty file named
 .Nm rc.conf.local .
 Edit the new file ... blah blah blah


Follows the diff suggesting the creation of an empty file. Stuart, I
don't think that in this case it's verbose. It's only changing the idea
of advisable with a strong suggestion. The strong, makes all
difference, specifically in the case mentioned on misc@, where the
poster did not carefully read the man page. As I mentioned, our brain
try to fill in the gaps and in this case, the word strong might shout:
Hey, this is important, pay attention. But since I'm not a native
English speaker, perhaps someone could suggest a change in the text both
of the man page and the faq.

Index: share/man/man8/rc.conf.8
===
RCS file: /cvs/src/share/man/man8/rc.conf.8,v
retrieving revision 1.20
diff -u -p -u -r1.20 rc.conf.8
--- share/man/man8/rc.conf.817 Mar 2012 14:46:40 -  1.20
+++ share/man/man8/rc.conf.810 Feb 2014 21:36:58 -
@@ -45,11 +45,13 @@ in the
 series in order to set shell variables used therein
 to control the behaviour of the scripts.
 .Pp
-It is advisable to leave
+We strongly suggest you do not alter
 .Nm rc.conf
-untouched, and instead create and edit a new
+itself. Instead create an empty file named
 .Nm rc.conf.local
-file.
+file and copy only the variables you wish to change from
+.Nm rc.conf
+and adjust them as you like.
 Variables set in this file will override variables previously set in
 .Nm rc.conf .
 .Pp

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Boot network for remote unlock of fde

Hi,

I have one linux server that has full disk encryption, and I use
it's initramfs with dropbear to be able to remote unlock the encrypted
root partition.

From what I read from the OpenBSD documentation, this is not
possible now. I want some guidance for what areas of code I would need
to modify, to accomplish the same. I know it would involve lots of
hacking with boot(8), with the kernel itself, and perhaps more. Also, I
want to know how hard you guys think it would be.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Boot network for remote unlock of fde

Em 05-03-2014 17:30, Ted Unangst escreveu:
 On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote:
 Hi,

 I have one linux server that has full disk encryption, and I use
 it's initramfs with dropbear to be able to remote unlock the encrypted
 root partition.

 From what I read from the OpenBSD documentation, this is not
 possible now. I want some guidance for what areas of code I would need
 to modify, to accomplish the same. I know it would involve lots of
 hacking with boot(8), with the kernel itself, and perhaps more. Also, I
 want to know how hard you guys think it would be.
 I'm aware of some issues in this area.

 You probably need to modify boot to default to serial console. The
 normal approach, taken by the installer, is to use boot.conf, but of
 course that's not readable before the disk is decrypted. This is
 assuming you will use serial console to provide the password instead
 of regular keyboard.

 If you want to provide the password over the network, I think that's
 going to be way more work. pxeboot may be a place to start, but I
 don't think you'll like where that leads and it won't be very secure
 either.

 Or get a server that supports some sort of kvm/console over IP.
Ted,

Thank you for your reply. I am tending for the generic solution for
unlocking it via network. Not using console nor any hardware assist. On
linux, using initramfs + busybox + dropbear + some other hacks, it works
quite well and secure, since you unlock it through ssh.

I took a look at pxeboot, but I don't think it will work. I know it
is a chicken-egg problem, but I want to take a shot at it. Just would
like some guidance, where to start. I know that maybe it would need some
approach in the lines of initramfs, but I would avoid it as much as I
can, if possible. I think a unencrypted partition/disklabel with
boot.conf and the kernel, plus some hack with boot itself to initialize
the network device, and configure it's ip address would be more
interesting. Or even just boot.conf on the partition. This would require
that boot(8) would do most of the work, even a small sshd
implementation. Any ideas?

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Boot network for remote unlock of fde

Em 05-03-2014 18:05, Stuart Henderson escreveu:
 On 2014/03/05 17:48, Giancarlo Razzolini wrote:
 Em 05-03-2014 17:30, Ted Unangst escreveu:
 On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote:
 Hi,

 I have one linux server that has full disk encryption, and I use
 it's initramfs with dropbear to be able to remote unlock the encrypted
 root partition.

 From what I read from the OpenBSD documentation, this is not
 possible now. I want some guidance for what areas of code I would need
 to modify, to accomplish the same. I know it would involve lots of
 hacking with boot(8), with the kernel itself, and perhaps more. Also, I
 want to know how hard you guys think it would be.
 I'm aware of some issues in this area.

 You probably need to modify boot to default to serial console. The
 normal approach, taken by the installer, is to use boot.conf, but of
 course that's not readable before the disk is decrypted. This is
 assuming you will use serial console to provide the password instead
 of regular keyboard.

 If you want to provide the password over the network, I think that's
 going to be way more work. pxeboot may be a place to start, but I
 don't think you'll like where that leads and it won't be very secure
 either.

 Or get a server that supports some sort of kvm/console over IP.
 Ted,

 Thank you for your reply. I am tending for the generic solution for
 unlocking it via network. Not using console nor any hardware assist. On
 linux, using initramfs + busybox + dropbear + some other hacks, it works
 quite well and secure, since you unlock it through ssh.
 I took a look at pxeboot, but I don't think it will work. I know it
 is a chicken-egg problem, but I want to take a shot at it. Just would
 like some guidance, where to start. I know that maybe it would need some
 approach in the lines of initramfs, but I would avoid it as much as I
 can, if possible. I think a unencrypted partition/disklabel with
 boot.conf and the kernel, plus some hack with boot itself to initialize
 the network device, and configure it's ip address would be more
 interesting. Or even just boot.conf on the partition. This would require
 that boot(8) would do most of the work, even a small sshd
 implementation. Any ideas?

 Cheers,

 -- 
 Giancarlo Razzolini
 GPG: 4096R/77B981BC

 What are you trying to protect against?

 If somebody has physical access, they can presumably replace the 
 kernel/initramfs
 with a trojanned version ...


I'm not trying to protect anything. Physical access almost always
means game over. There could be some work on the area of trusted
booting, using TPM chips, but this is another beast entirely.

I'm trying to be able to remote unlock my full disk encrypted
OpenBSD installation in a way that the keystrokes can't be intercepted
in the wire. There is already a protocol for this, which is ssh. The
trick is to have it working in the boot process.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Boot network for remote unlock of fde

Em 05-03-2014 19:03, Chris Cappuccio escreveu:

Personally I think this sort-of soft-IPMI is a pretty cool idea and I found
Matthieu's reply enlightening as well.

Apparently Linux has made some progress beyond pivot_root and there are
some interesting ideas there. (Note that we have a functioning tmpfs.)

http://www.spinics.net/lists/util-linux-ng/msg08794.html

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Evolving the kernel ramdisk to extract archive to a tmpfs might be the right
thing to do if the BSD tmpfs has the same advantages (doesn't run the
backing store back through the buffer cache etc.)

Chris,

The first answer that is trying to give some ideas, rather than just
criticizing security. I'm aware of all the shortcomings of this
solution. I had to hack some time with linux's initramfs to get some
sense of security. I even managed to have pppd embedded on it so I can
unlock my server over the internet, not just lan. I have it even to run
some script that set's it's ip address on my dns server that has it's
SSHFP record, so I won't be victim to impersonating attacks. It's
working quite well, I must say.

Physical access means game over, even more with the solution pointed
by you guys, of moving things and creating symlinks. It opens up more
attack vectors. Telling me to have another machine to redirect the
console to, booting with a pendrive, and every other ideas that rely on
external things, is not necessary. I'm aware of those possibilities.
Rather than that, what about contribute with ideas for this. I believe
that it's not only FDE unlocking that would benefit of early network. As
I mentioned before, the possibility of redirecting the console to the
ssh session is one of them. I believe that there are others. Come on
guys, I'm not asking for implementation, just want some pointers and
ideas. I know it would be a very hard task, but I would like the challenge.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Boot network for remote unlock of fde

Em 05-03-2014 23:01, Ted Unangst escreveu:
 If we're going to discuss things that would be useful, I have for
 quite some time wanted a kexec() syscall that loads a new kernel and
 reboots into it. I think that would be helpful for a variety of tasks,
 not least of which is avoiding the four minute BIOS countdown sequence
 on overengineered servers.

 As for FDE, you'd initially boot to a small, normal OpenBSD
 installation. Like an initramfs, but not all scrunched up. You login
 via ssh and run kexec /bsd sr0a:password or something,
 which tells the system to reboot with that kernel, except using softraid
 as the root partition.

Now we're talking. I thought of this also, didn't looked at the
complexity of it yet. Another task where it would be useful, is in
overwriting the RAM with /dev/zero or /dev/random. This approach is used
on TAILS live cd to wipe the RAM after use.

But I believe, not have looked much at the code yet, that the kexec()
approach would be simpler than implementing the pivot_root().

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: Boot network for remote unlock of fde