Re: CVE-2018-8897

2018-05-11 Thread IL Ka 
>
>
>> Then how do they implement memory watch?
>>
>
> Got me, but even the ancient, in-tree gdb is able to do so.  Have you
> consulted the gdb source?
>

I read gdb sources and found an asnwer,  but later I read docs and here it
is:
https://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.html

"Depending on your system, watchpoints may be implemented in software or
hardware.
GDB does software watchpointing by single-stepping your program and testing
the variable’s value each time,
which is hundreds of times slower than normal execution. "

For bsd, configure script checks GETDBREGS in ptrace.h. It exists in
freebsd but not in openbsd.
Then, "target_can_use_hardware_watchpoint" returns 0, and
"breakpoint.c" checks it, and switches to software watchpoints.
Same happens when debug registers are full even on linux, I assume.

Re: Status of mips64el packages for 6.3

2018-05-11 Thread Xiyue Deng 
On Fri, May 11, 2018 at 08:53:18PM +, Stuart Henderson wrote:
> On 2018-05-10, Xiyue Deng  wrote:
> > Hi,
> >
> > I noticed that a few days ago (maybe around Monday) the 6.3 release
> > page[1] has updated mips64el package count:
> >
> > mips64el: 8254
> >
> > A few days have passed however there is still no
> > /pub/OpenBSD/6.3/packages/mips64el available[2].  In the meantime, it
> > seems the snapshots packages were actually updated[3].  Just wonder
> > whether they were actually 6.3 packages, and if not, will 6.3 packages
> > be available?
> >
> > Thanks.
> >
> > [1] https://www.openbsd.org/63.html
> > [2] https://cdn.openbsd.org/pub/OpenBSD/6.3/packages/mips64el
> > [3] https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el
> >
> >
> 
> The files dated 4 May in snapshots/packages/mips64el are 6.3 release
> packages. You can use them from there for now (e.g. via "pkg_add -D snap");
> they're not likely to be superseded before the files are copied to the
> proper 6.3 directory.
> 
> 

Great to know! Hope 6.3 path will also be ready soon.

Re: Status of mips64el packages for 6.3

2018-05-11 Thread Xiyue Deng 
On Fri, May 11, 2018 at 08:20:24PM -, Christian Weisgerber wrote:
> On 2018-05-10, Xiyue Deng  wrote:
> 
> > I noticed that a few days ago (maybe around Monday) the 6.3 release
> > page[1] has updated mips64el package count:
> >
> > mips64el: 8254
> 
> Sorry, these are indeed ready, but they haven't been uploaded to
> the release directory yet.
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

Ah OK. Hope that happens soon.

Re: CVE-2018-8897

2018-05-11 Thread jungle Boogie 
On 5:58PM, Thu, May 10, 2018 Theo de Raadt  wrote:
>
> >Dare I ask what lead to OpenBSD not being affected.
> >
> >Sorry if it is a dumb question but since this hit FreeBSD as well I am
> >wondering
> >what OpenBSD did differently.
> >
> >Was this caught in an audit?
> >
> >I am just curious about causality that kept OpenBSD in the clear of this
one
> >that made such headlines yesterday.
>
>
> We didn't chase the fad of using every Intel cpu feature.
>

Once again, the puffer protects us again - secure by default.

Re: Status of mips64el packages for 6.3

2018-05-11 Thread Stuart Henderson 
On 2018-05-10, Xiyue Deng  wrote:
> Hi,
>
> I noticed that a few days ago (maybe around Monday) the 6.3 release
> page[1] has updated mips64el package count:
>
> mips64el: 8254
>
> A few days have passed however there is still no
> /pub/OpenBSD/6.3/packages/mips64el available[2].  In the meantime, it
> seems the snapshots packages were actually updated[3].  Just wonder
> whether they were actually 6.3 packages, and if not, will 6.3 packages
> be available?
>
> Thanks.
>
> [1] https://www.openbsd.org/63.html
> [2] https://cdn.openbsd.org/pub/OpenBSD/6.3/packages/mips64el
> [3] https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el
>
>

The files dated 4 May in snapshots/packages/mips64el are 6.3 release
packages. You can use them from there for now (e.g. via "pkg_add -D snap");
they're not likely to be superseded before the files are copied to the
proper 6.3 directory.

Re: Status of mips64el packages for 6.3

2018-05-11 Thread Christian Weisgerber 
On 2018-05-10, Xiyue Deng  wrote:

> I noticed that a few days ago (maybe around Monday) the 6.3 release
> page[1] has updated mips64el package count:
>
> mips64el: 8254

Sorry, these are indeed ready, but they haven't been uploaded to
the release directory yet.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: 6.3 - dhclient not working on wireless

2018-05-11 Thread Dumitru Mișu Moldovan 
On 05/06/18 11:39, Stefan Sperling wrote:
> On Sat, May 05, 2018 at 11:03:52PM +0200, Riccardo Mottola wrote:

[…]

> A commit of mine accidentally broke WEP support back in August 2017.
> This was eventually fixed in -current 2 weeks ago. Nobody noticed
> that WEP was broken for 8 months...

[…]

This must be the reason WEP networks never worked for me, couldn't
figure it why until now…  I am a newcomer in the OpenBSD world and could
never get to connect through wireless tethering using my phone.  The
Nokia N9 only supports WEP for encryption.  I've tried once using an
unencrypted network with the N9 as hotspot, but strangers started
stealing my precious mobile data, even when in a train, next to me!  :-]

The only other alternative was tethering through an USB cable, which is
cumbersome, first of all because I can only get an SSH connection to the
phone's Dropbear SSH server, through which I have to proxy everything.
Also, if I'm outside with my notebook, I would rather have my phone not
connected to it with a cable.

Would also much appreciate a fix for -stable, as -current is not
feasible for me, unfortunately, because of work-related issues.



signature.asc
Description: OpenPGP digital signature

WEP broken (was: Re: 6.3 - dhclient not working on wireless)

2018-05-11 Thread Stefan Sperling 
On Fri, May 11, 2018 at 04:56:19PM +0200, Riccardo Mottola wrote:
> Is a backport possible to "stable"?

I don't think it is worth the effort for us.

You are literally the only person I know of who has requested an
official backport of this fix. WEP was already broken in OpenBSD 6.2
which was released in October 2017. In all this time, nobody complained.
So it does not look like this problem affects many people.

The patch to fix WEP is trivial and should apply cleanly to
a 6.3 source tree if needed:

Index: ieee80211_proto.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_proto.c,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -p -r1.83 -r1.84
--- ieee80211_proto.c   6 Feb 2018 22:14:52 -   1.83
+++ ieee80211_proto.c   27 Apr 2018 15:33:49 -  1.84
@@ -1,4 +1,4 @@
-/* $OpenBSD: ieee80211_proto.c,v 1.83 2018/02/06 22:14:52 phessler Exp $   
*/
+/* $OpenBSD: ieee80211_proto.c,v 1.84 2018/04/27 15:33:49 stsp Exp $   
*/
 /* $NetBSD: ieee80211_proto.c,v 1.8 2004/04/30 23:58:20 dyoung Exp $   
*/
 
 /*-
@@ -948,7 +948,8 @@ justcleanup:
break;
}
ni->ni_rsn_supp_state = RSNA_SUPP_INITIALIZE;
-   ieee80211_crypto_clear_groupkeys(ic);
+   if (ic->ic_flags & IEEE80211_F_RSNON)
+   ieee80211_crypto_clear_groupkeys(ic);
break;
case IEEE80211_S_SCAN:
ic->ic_flags &= ~IEEE80211_F_SIBSS;
@@ -960,7 +961,8 @@ justcleanup:
ni->ni_associd = 0;
ni->ni_rstamp = 0;
ni->ni_rsn_supp_state = RSNA_SUPP_INITIALIZE;
-   ieee80211_crypto_clear_groupkeys(ic);
+   if (ic->ic_flags & IEEE80211_F_RSNON)
+   ieee80211_crypto_clear_groupkeys(ic);
switch (ostate) {
case IEEE80211_S_INIT:
 #ifndef IEEE80211_STA_ONLY
@@ -1006,7 +1008,8 @@ justcleanup:
break;
case IEEE80211_S_AUTH:
ni->ni_rsn_supp_state = RSNA_SUPP_INITIALIZE;
-   ieee80211_crypto_clear_groupkeys(ic);
+   if (ic->ic_flags & IEEE80211_F_RSNON)
+   ieee80211_crypto_clear_groupkeys(ic);
switch (ostate) {
case IEEE80211_S_INIT:
if (ifp->if_flags & IFF_DEBUG)

Re: 6.3 - dhclient not working on wireless

2018-05-11 Thread Riccardo Mottola 

Hi,

Stefan Sperling wrote:

The keyword 'nwkey' indicates you are using WEP. Is that correct?


Yes!



A commit of mine accidentally broke WEP support back in August 2017.
This was eventually fixed in -current 2 weeks ago. Nobody noticed
that WEP was broken for 8 months...


I did notice that actually, but I upgraded two computers on a different 
timeframe. The first one being old, i supposed had different issues, I 
thought it had an issue with the PCMCIA adapter.. so i was unable to do 
further test
When I updated a more modern ThinkPad which was known good and which has 
both wired and wireless integrated networks I was able to track it down.


Is a backport possible to "stable"?



I'd suggest switching this wifi network to WPA2, or just leaving it open
since WEP is no better than leaving your wifi open in the first place.


Well, almost, but at least people don't accidentally hack, but must do 
that on purpose..




We provide WEP only for interop with legacy networks outside your control.


That's the case... certain devices do not support WPA2 on that network 
so it stays such and data is encrypted on a higher level (e.g. ssh 
connections)


Riccardo

Re: Can SSH report successful connections to pf?

2018-05-11 Thread Lampshade 

>At the end of a "pass" rule in pf.conf, the author adds:
>
> max‐src‐conn 3, max‐src‐conn‐rate 2/5, overload  flush global
>
>which means:
>
> "any source can only have a total of three connections,
> and they may not create them at a rate faster than two
> every five minutes. If they do, they will be added to the
> abusers table and every packet/session will be globally
> dropped."
>
>I locked myself out of many boxes thanks to that.

As Peter pointed out it is best to set timeout/expiry date for IPs in blocklist.
One can also create whitelist for you own IPs. Personally I had checked IP
my ISP gave me, then checked by online services what AS number and CIDR
this IP is contained in. Then added to whitelist table. It creates some
hole in firewall, but proactive firewall based on blocklists in itself isn't 
strong
protection. It is mostly useful for performance reasons.

Re: CVE-2018-8897

2018-05-11 Thread Bogdan Kulbida 
I guess this is the main reason why we all love OpenBSD and an idea and a 
philosophy (and people) behind this great OS!

- Bogdan

> On May 11, 2018, at 6:49 AM, andrew fabbro  wrote:
> 
> "A statement...was mishandled in the development of some or all
> operating-system kernels..."
> 
> I think it's really "some" and the reason it's "some" and not "all" is
> OpenBSD.
> 
> On Thu, May 10, 2018 at 9:51 PM, John Long  wrote:
> 
>> On Thu, 2018-05-10 at 18:54 -0600, Theo de Raadt wrote:
 Dare I ask what lead to OpenBSD not being affected.
 
 Sorry if it is a dumb question but since this hit FreeBSD as well I
 am
 wondering
 what OpenBSD did differently.
 
 Was this caught in an audit?
 
 I am just curious about causality that kept OpenBSD in the clear of
 this one
 that made such headlines yesterday.
>>> 
>>> 
>>> We didn't chase the fad of using every Intel cpu feature.
>> 
>> This goes into the achive! Thank you for the slice of sanity in an
>> insane word.
>> 
>> /jl
>> 
>> 
> 
> 
> -- 
> andrew fabbro
> and...@fabbro.org

Re: OT: Yandex - was Re: Why is ftp option removed from installer?

2018-05-11 Thread Wayne Oliver 
On Thu, May 10, 2018 at 9:36 AM, Stuart Henderson  
wrote:

On 2018-05-10, Patrick Dohman  wrote:

Incidentally why are there no African mirrors aka Kenya etc?
Nobody has offered one; a significant amount of traffic would be used 
just keeping it up to date with snapshots, so it would only make 
sense for someone with a bunch of spare already-paid-for network 
capacity really. For releases, it's likely that at least one of the 
CDNs will do nicely, they're not so good for snapshots though.



Actually there is a South African mirror that I use, although not 
official.


http://openbsd.mirror.ac.za/
ftp://openbsd.mirror.ac.za/

Just FYI

Re: CVE-2018-8897

2018-05-11 Thread andrew fabbro 
"A statement...was mishandled in the development of some or all
operating-system kernels..."

I think it's really "some" and the reason it's "some" and not "all" is
OpenBSD.

On Thu, May 10, 2018 at 9:51 PM, John Long  wrote:

> On Thu, 2018-05-10 at 18:54 -0600, Theo de Raadt wrote:
> > > Dare I ask what lead to OpenBSD not being affected.
> > >
> > > Sorry if it is a dumb question but since this hit FreeBSD as well I
> > > am
> > > wondering
> > > what OpenBSD did differently.
> > >
> > > Was this caught in an audit?
> > >
> > > I am just curious about causality that kept OpenBSD in the clear of
> > > this one
> > > that made such headlines yesterday.
> >
> >
> > We didn't chase the fad of using every Intel cpu feature.
>
> This goes into the achive! Thank you for the slice of sanity in an
> insane word.
>
> /jl
>
>


-- 
andrew fabbro
and...@fabbro.org

ikev2 All incoming/outgoing traffic over IPsec?

2018-05-11 Thread Denis 
Hello,

I have working ikev2 tunnel between two virtual aliased subnets. But no
traffic over IPsec tunnel from $ext_if on server machine to $ext_if on
client machine and vice-versa. Both machines are using in production and
firewalled by PF.


# cat /etc/hostname.em1
### server $ext_if
dhcp
alias 192.168.5.1
255.255.255.0

  |
  | IPsec
  |

# cat /etc/hostname.axen0
### client $ext_if
dhcp
alias 192.168.6.1
255.255.255.0


I can ping each 'end' of IPsec virtual subnets from both side of tunnel
(after IP assigned to both gateways by ISP's dhcp), but no traffic though.

server# ping 192.168.6.1
64 bytes from 192.168.6.1: icmp_seq=0 ttl=255 time 1.064 ms
...
clielnt# ping 192.168.5.1
64 bytes from 192.168.5.1: icmp_seq=0 ttl=255 time 0.785 ms
...

The final goal is: All incoming traffic on server's $ext_if = "em1" for
selected ports 25, 443, 465, 993 etc. must be redirected from aliased
server's IP:192.168.5.1 though IPsec tunnel to appropriate services on
aliased client's IP:192.168.6.1. So client can reply to incoming
connections to remote server's via IPsec lan.

No routing is needed between server's / client's 'real' private LANs.
Because of that I've decided to use aliased virtual lans for IPsec
tunneling. But I'm not sure about correctness of this.

server# cat /etc/iked.conf
gw_ip = "em1"
local_lan = "192.168.5.0/24" # server side virtual subnet alias to em1 \
which obtain an address from dhcp
remote_lan = "192.168.6.0/24" # client virtual subnet alias to axen0 \
which obtain an address from dhcp too.
mode  = "passive"

ikev2 "pki-srv" $mode ipcomp esp \
from $local_lan to $remote_lan \
local $gw_ip peer any \
srcid srv-pubkey dstid clnt-pubkey \
tag "srv.tld.ipsec"
tap "enc0"

server# cat /etc/pf.conf
...
ext_if  = em1
ipsec_if= em1
ipsec_enc_if= enc0
ipsec_local_lan = "192.168.5.0/24"
ipsec_remote_lan = "192.168.6.0/24"
...
queue rootq on $ext_if bandwidth 100M max 100M
queue ipsec parent rootq bandwidth 90M min 70M max 100M
queue ipsec_users   parent rootq bandwidth 50M min 30M max 60M
queue bulk  parent rootq bandwidth 10M default
...
block on $ext_if all
block on $ipsec_enc_if all
...

# --- IPsec
pass in quick on $ipsec_if proto udp from any to ($ipsec_if) port \
{isakmp, ipsec-nat-t}
pass out quick on $ipsec_if proto udp from ($ipsec_if) to any port \
{isakmp, ipsec-nat-t} keep state

pass in quick on $ipsec_if proto esp from any to ($ipsec_if)
pass out quick on $ipsec_if proto exp from ($ipsec_if) to any \
keep state set queue ipsec

pass out quick on $ipsec_if tagged srv.tld.ipsec set queue ipsec_users

pass in quick on $ipsec_enc_if proto ipencap from any to ($ipsec_if) \
keep state (if-bound)
pass out quick on $ipsec_enc_if proto ipencap from ($ipsec_if) to any \
keep state (if-bound)

pass in quick on $ipsec_enc_if from $ipsec_remote_lan to \
$ipsec_local_lan keep state (if-bound)
pass out quick on $ipsec_enc_if from $ipsec_local_lan to \
$ipsec_remote_lan keep state (if-bound)
...


client# cat /etc/iked.conf
gw_ip = "axen0"
local_lan = "192.168.6.0/24" # clinet virtual subnet alias to axen0 \
which obtain an address from dhcp
remote_lan = "192.168.5.0/24" #server side virtual subnet alias to em0 \
which obtain an address from dhcp
srv_ip= "a.b.c.d" #server's IP each time is the same from ISP's dhcp
mode  = "active"

ikev2 "pki-clnt" $mode ipcomp esp \
from $local_lan to $remote_lan \
local $gw_ip to $srv_ip \
crcid clnt-pubkey dstid srv-pubkey \
tag "clnt.tld.ipsec"
tap "em0"

client# cat /etc/pf.conf
...
ext_if  = axen0
ipsec_if= axen0
ipsec_enc_if= enc0
ipsec_local_lan = "192.168.6.0/24"
ipsec_remote_lan = "192.168.5.0/24"
...
queue rootq on $ext_if bandwidth 100M max 100M
queue ipsec parent rootq bandwidth 90M min 70M max 100M
queue ipsec_users   parent rootq bandwidth 50M min 30M max 60M
queue bulk  parent rootq bandwidth 10M default
...
block on $ext_if all
block on $ipsec_enc_if all
...

# --- IPsec
pass in quick on $ipsec_if proto udp from any to ($ipsec_if) port \
{isakmp, ipsec-nat-t}
pass out quick on $ipsec_if proto udp from ($ipsec_if) to any port \
{isakmp, ipsec-nat-t} keep state

pass in quick on $ipsec_if proto esp from any to ($ipsec_if)
pass out quick on $ipsec_if proto exp from ($ipsec_if) to any \
keep state set queue ipsec

pass out quick on $ipsec_if tagged clnt.tld.ipsec set queue ipsec_users

pass in quick on $ipsec_enc_if proto ipencap from any to ($ipsec_if) \
keep state (if-bound)
pass out quick on $ipsec_enc_if proto ipencap from ($ipsec_if) to any \
keep state (if-bound)

pass in quick on $ipsec_enc_if from $ipsec_remote_lan to \
$ipsec_local_lan keep state (if-bound)
pass out quick on $ipsec_enc_if from $ipsec_local_lan to \
$ipsec_remote_lan keep

Re: CVE-2018-8897

2018-05-11 Thread John Long 
On Thu, 2018-05-10 at 18:54 -0600, Theo de Raadt wrote:
> > Dare I ask what lead to OpenBSD not being affected.
> > 
> > Sorry if it is a dumb question but since this hit FreeBSD as well I
> > am
> > wondering
> > what OpenBSD did differently.
> > 
> > Was this caught in an audit?
> > 
> > I am just curious about causality that kept OpenBSD in the clear of
> > this one
> > that made such headlines yesterday.
> 
> 
> We didn't chase the fad of using every Intel cpu feature.

This goes into the achive! Thank you for the slice of sanity in an
insane word.

/jl