/bin/ksh ksh(1) typeset -p output weirdness

[tom]

>Synopsis:  ksh(pd) `typeset -p` lists all variables as readonly
>Category:  user
>Environment:
System  : OpenBSD 6.2
Details : OpenBSD 6.2 (GENERIC.MP) #5: Fri Feb  2 23:02:19 CET 2018
 
r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
The ksh(1) man page describes the `-p` option as being equivalent
to the default of no parameters, but actually using the `-p` option
results in a very different output with the somewhat bizarre
behavior of prefixing each variable with "readonly "
>How-To-Repeat:
From within ksh issue the command `typeset -p`
>Fix:
Within the source code (src/bin/ksh/c_ksh.c), the offending lines
test the pflag variable and if set test the variable `flag` instead
of testing `vp->flag` and further assume that the a shell variable
can only be EXPORT or RDONLY.

The following patch will fix that behavior but it still won't be
consistent with the manual. And the default printout and the `-p`
format of ksh93 is the reverse of what the fix will do, though that
seems to be what the code intended to do anyway.

Possibly a better fix would be to remove the special handling of
the `-p` format.


Index: c_ksh.c
===
RCS file: /home/tw/src/sys/openbsd-cvs/src/bin/ksh/c_ksh.c,v
retrieving revision 1.58
diff -u -p -r1.58 c_ksh.c
--- c_ksh.c 16 Jan 2018 22:52:32 -  1.58
+++ c_ksh.c 7 Feb 2018 23:09:06 -
@@ -790,10 +790,12 @@ c_typeset(char **wp)
if (vp->flag)
break;
} else {
-   if (pflag)
-   shprintf("%s ",
-   (flag & EXPORT) ?
-   "export" : 
"readonly");
+   if (pflag) {
+   if (vp->flag & EXPORT)
+   
shprintf("export ");
+   else if 
((vp->flag))
+   
shprintf("readonly ");
+   }
if ((vp->flag) && any_set)
shprintf("%s[%d]",
vp->name, 
vp->index);

Re: syspatch not installing 6.1 binary patches

[R0me0 ***]

Hello guys,

Clarified! Thank you so much all.



2018-02-07 18:17 GMT-02:00 Raf Czlonka :

> R0me0,
>
> Syspatch has been around *since* 6.1 - yes.
>
> Like Bryan already mentioned, binary patches are *only* available
> for the most recent release, though - it being 6.2.
>
> Cheers,
>
> Raf
>
> On Wed, Feb 07, 2018 at 07:33:16PM GMT, R0me0 *** wrote:
> > Hello, I got confused, since I already applied a lot on 6.1?
> > AFAIK , syspatch is supported since 6.1
> >
> > Regards,
> >
> >
> >
> > 2018-02-04 14:30 GMT-02:00 Bryan Steele :
> >
> > > On Sun, Feb 04, 2018 at 09:57:39AM -0200, R0me0 *** wrote:
> > > > Hello guys,
> > > >
> > > > I am trying to apply binary patches on 6.1 and syspatch isn't able to
> > > find
> > > > them
> > > >
> > > > on 6.2 works as expected.
> > > >
> > > > syspatch
> > > > -l
> > > >
> > > >
> > > > 001_dhcpd
> > > > 002_vmmfpu
> > > > 003_libressl
> > > > 004_softraid_concat
> > > > 005_pf_src_tracking
> > > > 006_libssl
> > > > 007_freetype
> > > > 008_exec_subr
> > > > 009_icmp_opts
> > > > 010_perl
> > > > 012_wsmux
> > > > 013_icmp6_linklocal
> > > > 014_libcrypto
> > > > 015_sigio
> > > > 016_sendsyslog
> > > > 017_fuse
> > > > 018_recv
> > > > 019_tcp_usrreq
> > > > 020_sockaddr
> > > > 021_ptrace
> > > > 022_fcntl
> > > > 023_wsdisplay
> > > > 024_sosplice
> > > > 025_ieee80211
> > > > 026_smap
> > > > 027_net80211_replay
> > > > 028_perl
> > > > 029_tcb
> > > > 030_xrstor
> > > > 031_xrstor_resume
> > >
> > > syspatch is only supported on the latest OpenBSD release, 6.2.
> > >
> > > See ajacoutot@'s FOSDEM 2018 talk:
> > > https://fosdem.org/2018/schedule/event/openbsd_base_
> > > system_maintenance_made_easy/
> > >
> > > -Bryan.
> > >
> > >
>

Re: syspatch not installing 6.1 binary patches

[Raf Czlonka]

R0me0,

Syspatch has been around *since* 6.1 - yes.

Like Bryan already mentioned, binary patches are *only* available
for the most recent release, though - it being 6.2.

Cheers,

Raf

On Wed, Feb 07, 2018 at 07:33:16PM GMT, R0me0 *** wrote:
> Hello, I got confused, since I already applied a lot on 6.1?
> AFAIK , syspatch is supported since 6.1
> 
> Regards,
> 
> 
> 
> 2018-02-04 14:30 GMT-02:00 Bryan Steele :
> 
> > On Sun, Feb 04, 2018 at 09:57:39AM -0200, R0me0 *** wrote:
> > > Hello guys,
> > >
> > > I am trying to apply binary patches on 6.1 and syspatch isn't able to
> > find
> > > them
> > >
> > > on 6.2 works as expected.
> > >
> > > syspatch
> > > -l
> > >
> > >
> > > 001_dhcpd
> > > 002_vmmfpu
> > > 003_libressl
> > > 004_softraid_concat
> > > 005_pf_src_tracking
> > > 006_libssl
> > > 007_freetype
> > > 008_exec_subr
> > > 009_icmp_opts
> > > 010_perl
> > > 012_wsmux
> > > 013_icmp6_linklocal
> > > 014_libcrypto
> > > 015_sigio
> > > 016_sendsyslog
> > > 017_fuse
> > > 018_recv
> > > 019_tcp_usrreq
> > > 020_sockaddr
> > > 021_ptrace
> > > 022_fcntl
> > > 023_wsdisplay
> > > 024_sosplice
> > > 025_ieee80211
> > > 026_smap
> > > 027_net80211_replay
> > > 028_perl
> > > 029_tcb
> > > 030_xrstor
> > > 031_xrstor_resume
> >
> > syspatch is only supported on the latest OpenBSD release, 6.2.
> >
> > See ajacoutot@'s FOSDEM 2018 talk:
> > https://fosdem.org/2018/schedule/event/openbsd_base_
> > system_maintenance_made_easy/
> >
> > -Bryan.
> >
> >

Re: syspatch not installing 6.1 binary patches

[R0me0 ***]

Hello, I got confused, since I already applied a lot on 6.1?
AFAIK , syspatch is supported since 6.1

Regards,



2018-02-04 14:30 GMT-02:00 Bryan Steele :

> On Sun, Feb 04, 2018 at 09:57:39AM -0200, R0me0 *** wrote:
> > Hello guys,
> >
> > I am trying to apply binary patches on 6.1 and syspatch isn't able to
> find
> > them
> >
> > on 6.2 works as expected.
> >
> > syspatch
> > -l
> >
> >
> > 001_dhcpd
> > 002_vmmfpu
> > 003_libressl
> > 004_softraid_concat
> > 005_pf_src_tracking
> > 006_libssl
> > 007_freetype
> > 008_exec_subr
> > 009_icmp_opts
> > 010_perl
> > 012_wsmux
> > 013_icmp6_linklocal
> > 014_libcrypto
> > 015_sigio
> > 016_sendsyslog
> > 017_fuse
> > 018_recv
> > 019_tcp_usrreq
> > 020_sockaddr
> > 021_ptrace
> > 022_fcntl
> > 023_wsdisplay
> > 024_sosplice
> > 025_ieee80211
> > 026_smap
> > 027_net80211_replay
> > 028_perl
> > 029_tcb
> > 030_xrstor
> > 031_xrstor_resume
>
> syspatch is only supported on the latest OpenBSD release, 6.2.
>
> See ajacoutot@'s FOSDEM 2018 talk:
> https://fosdem.org/2018/schedule/event/openbsd_base_
> system_maintenance_made_easy/
>
> -Bryan.
>
>

Re: Further progress on breaking RSA without factoring

[Theo de Raadt]

Radu -

Oh the righteous indignation of public discussion!  Stomp stomp.  Do you
feel better?  Go have a teary elsewhere.

>Dear Grabriel,
>
>To be honest, I didn't have the motivation to understand the attack. 
>However, the way you handle the disclosure bothers me.
>Instead of spamming in a "bug" openbsd mailing list and Reddit, do the 
>following:
>1) contact a "crypto mathematician expert" from the closest 
>university/google/.../etc and convince him that you are right;
>2) he will certainly help you write a research paper and submit to a 
>well known crypto conference;
>3) wait for other experts around the world to find flaws in your reasoning.
>If it occurs that you are right, people will react.
>
>Sincerely,
>Radu
>
>On 02/02/2018 09:25 PM, Gabriel Withington wrote:
>> The common complaint that I've received about my attack is that it doesn't
>> work on real keys in real time on my laptop. Now, this is a silly bar to
>> set. The real question is what happens on a fast computer. (If I can break
>> a 1024 bit key in 1000 years on my computer, this is a significant
>> improvement over current methods and will put keys at risk on a
>> supercomputer. I don't have 1000 years or a supercomputer.)
>>
>> But I take the point and I've been working on it. And I think I've got it.
>>
>> What we're looking for is a loop exponent 'k' for message 'm' and semiprime
>> 'n' such that m^k % n = 1. In order for this to be true m^k - 1 = a*n for
>> some integer 'a'. And if we can stick to m=2 for a moment then 2^k - 1 is
>> going to be of a known form - a binary number with every digit equal to 1.
>> Which means that if we can find an integer 'a' such that a*n is all 1s in
>> binary then we can easily find 'k'. And this is actually really
>> straightforward.
>>
>> In fact, ignoring the nasty underflow problem Perl has with their bignum
>> arbitrary precision package which gives faulty values for really small
>> values of 'n', I'm able to quickly find the smallest loop exponent for 2
>> and a given semiprime. And it takes 'k' operations. (I've attached my proof
>> of concept code. It's messy and uncommented but it works for values that
>> don't fail due to underflow).
>>
>> I haven't tried to extend this to other messages yet but it seems like it
>> could be straightforward - m^k - 1 expressed in base 'm' will always be a
>> string of digits which equal m-1. It's easy to find the values in binary,
>> in other bases it will be given by a*b % m = m-1 (or something like that).
>>
>> But even if this approach is somehow unusable in other bases, it gives the
>> minimum loop exponent for m=2 and that is worth quite a lot. The loop
>> exponent for 2 can then be fed into my original search to scale the
>> exponents and greatly accelerate things. And the loop exponent will also
>> work for lots of other messages.
>>
>> So I'm still working on this but I'm getting close to making this run very
>> fast. Which was really my bigger point all along. It's not that I thought I
>> found the fastest method, I simply saw the existence of a vulnerability
>> which allowed for decryption without factoring as a point for serious
>> concern. The concern being that somebody could look at what I had done so
>> far and come up with a really fast method to break keys. Which might be
>> exactly where I am.
>>
>> Let me know if your people have any thoughts or questions.
>>
>> Thanks!
>> Gabriel
>
>
>

Re: Further progress on breaking RSA without factoring

[At0mik]

Dear Grabriel,

To be honest, I didn't have the motivation to understand the attack. 
However, the way you handle the disclosure bothers me.
Instead of spamming in a "bug" openbsd mailing list and Reddit, do the 
following:
1) contact a "crypto mathematician expert" from the closest 
university/google/.../etc and convince him that you are right;
2) he will certainly help you write a research paper and submit to a 
well known crypto conference;

3) wait for other experts around the world to find flaws in your reasoning.
If it occurs that you are right, people will react.

Sincerely,
Radu

On 02/02/2018 09:25 PM, Gabriel Withington wrote:

The common complaint that I've received about my attack is that it doesn't
work on real keys in real time on my laptop. Now, this is a silly bar to
set. The real question is what happens on a fast computer. (If I can break
a 1024 bit key in 1000 years on my computer, this is a significant
improvement over current methods and will put keys at risk on a
supercomputer. I don't have 1000 years or a supercomputer.)

But I take the point and I've been working on it. And I think I've got it.

What we're looking for is a loop exponent 'k' for message 'm' and semiprime
'n' such that m^k % n = 1. In order for this to be true m^k - 1 = a*n for
some integer 'a'. And if we can stick to m=2 for a moment then 2^k - 1 is
going to be of a known form - a binary number with every digit equal to 1.
Which means that if we can find an integer 'a' such that a*n is all 1s in
binary then we can easily find 'k'. And this is actually really
straightforward.

In fact, ignoring the nasty underflow problem Perl has with their bignum
arbitrary precision package which gives faulty values for really small
values of 'n', I'm able to quickly find the smallest loop exponent for 2
and a given semiprime. And it takes 'k' operations. (I've attached my proof
of concept code. It's messy and uncommented but it works for values that
don't fail due to underflow).

I haven't tried to extend this to other messages yet but it seems like it
could be straightforward - m^k - 1 expressed in base 'm' will always be a
string of digits which equal m-1. It's easy to find the values in binary,
in other bases it will be given by a*b % m = m-1 (or something like that).

But even if this approach is somehow unusable in other bases, it gives the
minimum loop exponent for m=2 and that is worth quite a lot. The loop
exponent for 2 can then be fed into my original search to scale the
exponents and greatly accelerate things. And the loop exponent will also
work for lots of other messages.

So I'm still working on this but I'm getting close to making this run very
fast. Which was really my bigger point all along. It's not that I thought I
found the fastest method, I simply saw the existence of a vulnerability
which allowed for decryption without factoring as a point for serious
concern. The concern being that somebody could look at what I had done so
far and come up with a really fast method to break keys. Which might be
exactly where I am.

Let me know if your people have any thoughts or questions.

Thanks!
Gabriel

Re: wifi not resuming after zzz

[Stefan Sperling]

On Tue, Feb 06, 2018 at 08:10:10PM -0700, Richard Johnson wrote:
> I initially noticed problems after I upgraded from 6.2 stable to the 6.2
> 2018-02-01 and 2018-02-05 snapshots. My trunk0 interface stopped being able
> to use iwn0 on the 5GHz SSID for failover at boot time.
> However, using the 2.4GHz SSID for failover works.
> I can get 5GHz SSID working by first bringing iwn0 up on the 2.4GHz SSID,
> then changing to the 5GHz SSID. One way: edit hostname.iwn0 and `doas sh
> /etc/netstart iwn0`.
> A zzz then sticks iwn0 in a non-responsive state.
> If I then `ifconfig iwn0 down delete`, and switch back to the 2.4GHz SSID
> (edit hostname.iwn0, redo netstart), I again get a working iwn0 on the
> 2.4GHz net.
> From there, I can switch back to the 5GHz SSID as above, until reboot or zzz
> requires a repeat.

There is a known behaviour of the firmware where, on a 5 GHz channel,
it will not transmit a probe request unless it first sees some other
valid packet on the channel. This has to do with how the firmware deals
with regulatory domains, which restrict 5Ghz channels in some parts of
the world. I don't really understand exactly how it works, and how we
can control it. But there are some parameters which go into the scan
command which you could try tweaking to see if they have any effect,
and let us know your results.

If you want to try playing with these parameters to the firmware,
(i.e. change them, recompile kernel, and test) you can find them
in if_iwnreg.h:

/*
 * For active scan, listen ACTIVE_DWELL_TIME (msec) on each channel after
 * sending probe req.  This should be set long enough to hear probe responses
 * from more than one AP.
 */
#define IWN_ACTIVE_DWELL_TIME_2GHZ  (30)/* all times in msec */
#define IWN_ACTIVE_DWELL_TIME_5GHZ  (20)
#define IWN_ACTIVE_DWELL_FACTOR_2GHZ(3)
#define IWN_ACTIVE_DWELL_FACTOR_5GHZ(2)

/*
 * For passive scan, listen PASSIVE_DWELL_TIME (msec) on each channel.
 * Must be set longer than active dwell time.
 * For the most reliable scan, set > AP beacon interval (typically 100msec).
 */
#define IWN_PASSIVE_DWELL_TIME_2GHZ (20)/* all times in msec */
#define IWN_PASSIVE_DWELL_TIME_5GHZ (10)
#define IWN_PASSIVE_DWELL_BASE  (100)
#define IWN_CHANNEL_TUNE_TIME   (5)

The firmware command is built in at iwn_scan() in if_iwn.c, so see
there for more details.

An 'active scan' happens if you have an SSID configured with 'ifconfig iwn0
nwid foo', and 'passive scan' happens if no SSID is configured.

My theory is that because of the firmware's behaviour described above,
sometimes 5Ghz APs do not show up in the list, as you can see in debug
output I'm quoting below.

> iwn0: end active scan
>  - 02:6b:9e:84:48:20   11  +181 54M   ess  privacy   rsn  "DIRECT-JC-VIZIOTV"!
>  - 04:bf:6d:c1:24:8f   11  +182 54M   ess  privacy   rsn  "OwlAmigas"!
>  - 06:0e:83:a3:6f:9f1  +185 54M   ess   no!  rsn! "xfinitywifi"!
>  - 06:0e:83:a3:6f:a0  149  +171 54M   ess   no!  rsn! "xfinitywifi"!
>  - 10:13:31:28:85:921  +181 54M   ess  privacy   rsn  "CenturyLink3108"!
>  - 2c:30:33:7b:29:136  +178 54M   ess  privacy   rsn  "Wonka"!
>  - 38:63:bb:74:a1:d3   11  +180 54M   ess  privacy   rsn
> "HP-Print-D3-Officejet Pro 8610"!
>  - 58:8b:f3:d6:97:63   11  +186 54M   ess  privacy   rsn  "Owlhaus"!
>  - 58:8b:f3:e2:cb:b9   11  +183 54M   ess  privacy   rsn  "CenturyLink7111"!
>  + c4:ea:1d:96:d6:7b1  +227 54M   ess  privacy   rsn  "Rope"
>  - c4:ea:1d:96:d6:80   48  +223 54M   ess  privacy   rsn  ""!
>  - c4:ea:1d:96:d6:81   48  +223 54M   ess  privacy   rsn  "Rope-5G"!

Here it was found (but it didn't match our configured SSID) ^

>  - e4:18:6b:e6:94:8b3  +185 54M   ess  privacy   rsn  "CenturyLink2479"!
>  - f4:0e:83:a3:6f:9f1  +185 54M   ess  privacy   rsn  "CurlySam"!

> iwn0: end active scan
>  - 06:0e:83:a3:6f:9f1  +187 54M   ess   no!  rsn! "xfinitywifi"!
>  - 10:13:31:28:85:921  +180 54M   ess  privacy   rsn  "CenturyLink3108"!
>  - 16:0e:83:a3:6f:a0  149  +171 54M   ess  privacy   rsn  ""!
>  - 2c:30:33:7b:29:136  +179 54M   ess  privacy   rsn  "Wonka"!
>  - 38:63:bb:74:a1:d3   11  +183 54M   ess  privacy   rsn
> "HP-Print-D3-Officejet Pro 8610"!
>  - 58:8b:f3:d6:97:63   11  +182 54M   ess  privacy   rsn  "Owlhaus"!
>  - 58:8b:f3:e2:cb:b9   11  +183 54M   ess  privacy   rsn  "CenturyLink7111"!
>  - 5c:8f:e0:6a:10:ac1  +187 54M   ess  privacy   rsn  "RedHouse"!
>  - 6e:8f:e0:6a:10:ac1  +196 54M   ess   no!  rsn! "xfinitywifi"!
>  - 9e:8f:e0:6a:10:b1   36  +191 54M   ess  privacy   rsn! ""!
>  + c4:ea:1d:96:d6:7b1  +227 54M   ess  privacy   rsn  "Rope"
>  - e0:b9:e5:87:3a:308  +181 54M   ess  privacy   rsn  "CenturyLink3451"!

This time it was not found, even though other 5GHz APs are in the list.
So the firmware didn't pass your AP's beacon/probe response to the driver,
probably because it never received it.