leaf-devel — This is a discussion list for development topics.

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit [42635b] by kapeka

[KP K. <ka...@us...>]

You see commit messages? I don't...

On Do, 2018-02-22 at 18:53 +0000, Erich Titl wrote:
> Hi KP
> 
> This is not a good method to handle .htpasswd. Now it will not be in
> webconf.local anymore and all is lost.

I think it works.

# cat /var/lib/lrpkg/webconf.local  
etc/webconf/webconf.conf
var/webconf/lib/filter
var/webconf/templates
var/webconf/www/.htpasswd




> Please slow down.
> 
> cheers
> 
> ET
> 
> 
> -------- Weitergeleitete Nachricht --------
> Betreff: 	[leaf:bering-uclibc] New commit [42635b] by kapeka
> Datum: 	Thu, 22 Feb 2018 16:57:31 -0000
> Von: 	LEAF Linux Embedded Appliance Framework Git repository
> <no...@be...>
> Antwort an: 	LEAF Linux Embedded Appliance Framework Git
> repository
> <no...@be...>
> An: 	LEAF Linux Embedded Appliance Framework Git repository
> <no...@be...>
> 
> 
> 
>     Branch: master
> 
> webconf: remove default .htpasswd
> 
> make .htpasswd type local to save it when created.
> That way we don't provide a default .htpasswd which is really
> unsecure.
> File will be created during first install via root/.profile
> An existing .htpasswd will not be overwritten during upgrade because
> there is none in the package
> anymore.
> 
> webconf depends on htpasswd package now to be able to generate one
> via
> /usr/sbin/htpasswd.
> 
> By kapeka on 02/22/2018 16:51
> *View Changes*
> <https://sourceforge.net/p/leaf/bering-uclibc/ci/42635b69372690d27e58
> 0deced18762c6862a2f5/>
> 
> -------------------------------------------------------------------
> -----
> 
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
> 
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
> 
> 
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit [42635b] by kapeka

[KP K. <ka...@us...>]

Hi Erich;

On Do, 2018-02-22 at 18:53 +0000, Erich Titl wrote:
> Hi KP
> 
> This is not a good method to handle .htpasswd. Now it will not be in
> webconf.local anymore and all is lost.
> 
> Please slow down.

I've tested sucessfully locally and committed so everyone can test and
improve if needed.

kp

> cheers
> 
> ET
> 
> 
> -------- Weitergeleitete Nachricht --------
> Betreff: 	[leaf:bering-uclibc] New commit [42635b] by kapeka
> Datum: 	Thu, 22 Feb 2018 16:57:31 -0000
> Von: 	LEAF Linux Embedded Appliance Framework Git repository
> <no...@be...>
> Antwort an: 	LEAF Linux Embedded Appliance Framework Git
> repository
> <no...@be...>
> An: 	LEAF Linux Embedded Appliance Framework Git repository
> <no...@be...>
> 
> 
> 
>     Branch: master
> 
> webconf: remove default .htpasswd
> 
> make .htpasswd type local to save it when created.
> That way we don't provide a default .htpasswd which is really
> unsecure.
> File will be created during first install via root/.profile
> An existing .htpasswd will not be overwritten during upgrade because
> there is none in the package
> anymore.
> 
> webconf depends on htpasswd package now to be able to generate one
> via
> /usr/sbin/htpasswd.
> 
> By kapeka on 02/22/2018 16:51
> *View Changes*
> <https://sourceforge.net/p/leaf/bering-uclibc/ci/42635b69372690d27e58
> 0deced18762c6862a2f5/>
> 
> -------------------------------------------------------------------
> -----
> 
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
> 
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
> 
> 
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit [112d0f] by kapeka

[KP K. <ka...@us...>]

Hi Erich;

On Do, 2018-02-22 at 18:51 +0000, Erich Titl wrote:
> Hi KP
> 
> I am nor sure this is a good patch, if we save syslinux then we
> should
> save the complete syslinux directory along with syslinux.conf.

The approach to save syslinux/* does not work; we can add syslinux.cfg
as well, any other files in syslinux dir or improve the save function.

kp

> cheers
> 
> ET
> 
> 
> -------- Weitergeleitete Nachricht --------
> Betreff: 	[leaf:bering-uclibc] New commit [112d0f] by kapeka
> Datum: 	Thu, 22 Feb 2018 16:38:25 -0000
> Von: 	LEAF Linux Embedded Appliance Framework Git repository
> <no...@be...>
> Antwort an: 	LEAF Linux Embedded Appliance Framework Git
> repository
> <no...@be...>
> An: 	LEAF Linux Embedded Appliance Framework Git repository
> <no...@be...>
> 
> 
> 
>     Branch: master
> 
> webconf: make shure we save the kernel in syslinux/linux
> 
> By kapeka on 02/22/2018 16:34
> *View Changes*
> <https://sourceforge.net/p/leaf/bering-uclibc/ci/112d0f5f2d62c88abb04
> 4050fdefe9173d43d4db/>
> 
> -------------------------------------------------------------------
> -----
> 
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
> 
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
> 
> 
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] Fwd: [leaf:bering-uclibc] New commit [42635b] by kapeka

[Erich T. <eri...@th...>]

Hi KP

This is not a good method to handle .htpasswd. Now it will not be in
webconf.local anymore and all is lost.

Please slow down.

cheers

ET


-------- Weitergeleitete Nachricht --------
Betreff: 	[leaf:bering-uclibc] New commit [42635b] by kapeka
Datum: 	Thu, 22 Feb 2018 16:57:31 -0000
Von: 	LEAF Linux Embedded Appliance Framework Git repository
<no...@be...>
Antwort an: 	LEAF Linux Embedded Appliance Framework Git repository
<no...@be...>
An: 	LEAF Linux Embedded Appliance Framework Git repository
<no...@be...>



    Branch: master

webconf: remove default .htpasswd

make .htpasswd type local to save it when created.
That way we don't provide a default .htpasswd which is really unsecure.
File will be created during first install via root/.profile
An existing .htpasswd will not be overwritten during upgrade because
there is none in the package
anymore.

webconf depends on htpasswd package now to be able to generate one via
/usr/sbin/htpasswd.

By kapeka on 02/22/2018 16:51
*View Changes*
<https://sourceforge.net/p/leaf/bering-uclibc/ci/42635b69372690d27e580deced18762c6862a2f5/>

------------------------------------------------------------------------

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/leaf/bering-uclibc/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[leaf-devel] Fwd: [leaf:bering-uclibc] New commit [112d0f] by kapeka

[Erich T. <eri...@th...>]

Hi KP

I am nor sure this is a good patch, if we save syslinux then we should
save the complete syslinux directory along with syslinux.conf.

cheers

ET


-------- Weitergeleitete Nachricht --------
Betreff: 	[leaf:bering-uclibc] New commit [112d0f] by kapeka
Datum: 	Thu, 22 Feb 2018 16:38:25 -0000
Von: 	LEAF Linux Embedded Appliance Framework Git repository
<no...@be...>
Antwort an: 	LEAF Linux Embedded Appliance Framework Git repository
<no...@be...>
An: 	LEAF Linux Embedded Appliance Framework Git repository
<no...@be...>



    Branch: master

webconf: make shure we save the kernel in syslinux/linux

By kapeka on 02/22/2018 16:34
*View Changes*
<https://sourceforge.net/p/leaf/bering-uclibc/ci/112d0f5f2d62c88abb044050fdefe9173d43d4db/>

------------------------------------------------------------------------

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/leaf/bering-uclibc/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

Re: [leaf-devel] lighttpd with empty password

[Erich T. <eri...@th...>]

Hi KP

Am 15.02.2018 um 15:20 schrieb KP Kirchdoerfer:
> On Mi, 2018-02-14 at 20:49 +0000, Erich Titl wrote:
>> Hi KP
>>
> 
> On Di, 2018-02-13 at 19:14 +0000, Erich Titl wrote:
>> Hi KP
>>
>> Am 13.02.2018 um 18:10 schrieb KP Kirchdoerfer via leaf-devel:
>>> Hi Erich;
>>> On Di, 2018-02-13 at 13:31 +0000, Erich Titl wrote:
>>>> Hi
>>>>
>>>> Here a possible solution for the distribution of webconf with an
>>>> empty
>>>> passsword.
>>>>
>>>> leaftester# more .htpasswd
>>>> admin:2Dp46HA3ULDxA
>>>>
>>>> This password has been created using
>>>>
>>>> pwcrypt ""
>>>>
>>>
>>> Been there done that, it doesn't work.
>>
>> It does work, please state your observation.
> 
> Technically it works, but one don't even has to change the password to
> get full access, so it's worse than before where we have had an
> insecure web access, but at least the user was forced to change the
> default (empty) password to continue.
> 
>>>
>>> The previous behaviour with mini_httpd was with an empty password
>>> it
>>> does not show anything unless you add a password after login as
>>> admin -
>>> it always pointed to passwd.cgi regradless what link you wanted to
>>> open
>>> in webconf.

This is not true as of 6.1.1.

You can access anything you want with a missing .htpasswd or a .htpasswd
without password.

Firefox will just display a message that it intercepted the redirectioon
and happily connect :-(

So this is just mocked up security.

>>> Though everyone able to connect was able to login and change the
>>> password and get acccess to the router.
>>>
>>> This is in reality an illusion of security.
>>
>> This is not an illusion of security, this is no security, but
>> this is the way you can login with lighttpd and admin without knowing
>> a
>> password, as this is just the empty password.
>>
>> - You _cannot_ login using lighttpd _and_ a missing .htpasswd right
>> now.
>> - You _cannot_ login using lighttpd _and_ an empty password field in
>> .htpasswd right now.
>>
>> So user access is broken, this method gives you a chance to login and
>> _change_ the password to your own discretion. You will not be able to
>> do
>> that with the current empty password field.
> 
> True.
> 
>>>
>>> With lighttpd a really empty password in .htpasswd does not allow
>>> any
>>> login.
>>
>> Yes it does not, but with a encrypted empty password it does.
> 
> 
>>>
>>> The approach above allows to login with an empty password, but as
>>> you
>>> have a password, even an empty one, you have full access. Worse
>>> than
>>> before - and no better than having an open router without any
>>> protection.
>>
>> I don't get your idea. This enables the user to do _something_ just
>> like
>> before. With the current setttings the user is left alone.
> 
> We've learned (at least I have learned the last days) either way
> (previous and with your patch) is without any real security as long as
> you install webconf (esp if opened to WAN e.g. by accident).

Absolutely

> 
> 
>>>
>>> Commercial routers often uses a default password, like "1234" for a
>>> device I've installed recently in modem-mode before the LEAF router
>>> and
>>> you shall change it, but it works also without any changes. 
>>>
>>> I think we can do better.
>>
>> Commercial routers do exactly that and I agree it is bad. Now with
>> lighttpd being a bit more restrictive than mhttpd(s) when it comes to
>> .htpasswd we are in a small impasse.
>>
>>>
>>> We should get rid of any mimic to allow access from anywhere
>>> without a
>>> proper password choosen by the user.
>>
>> Do it with a script when starting a newly installed LEAF, that is
>> fine.
>> Do it with a post_install script in upgrade.
>>
>> But what about users choosing to manually upgrade like Timothy?
> 
> 
> 1) Do not provide any .htpasswd with webconf, but take to save it, once
> it is set (-> webconf buildtool.cfg needs to be changed)
> 
> 2) try to add a script for first install if webconf but no .htpassswd
> create one during installation like root password - if the user chooses
> an empty one here so be it.
> 
> 3) Users with a .htpasswd, hopefully changed password in the past, and
> it won't be acffected when upgrading, because there is no default
> .httpasswd any longer.
> 
> 4) the same counts for upgrades with upgrade tool, so I do not see a
> need for adding a script in post_upgrade

If we do not provide a .htpasswd in the package, then there is no way it
is saved in configdb.lrp as of the current buildtool environment. And I
have no clue what apkg -u will do.

> 
> 5) 1 to 4 needs to tested.
> 
> 
>>>
>>> So the "problems" seen with the change to lighttpd are a benefit in
>>> hindsight.
>>
>> ??????
> 
> I've never thouht a lot about webconf login cause I don't use it. The
> report on leaf-user changed that.
> 
>>>
>>> I tend to go the way:
>>>
>>> - no access to webconf without a real password as default
>>
>> Choose one, then publish it like the commercial vendors :-) Nothing
>> really new and not secure at all.
> 
>>> - it should be possible to change the web login password from the
>>> webpage
>>
>> This is a hen-egg problem with lighttpd. If you find another solution
>> which is _secure_, welcome to the club.
> 
> Here I've been unclear - let's not set the first password from port
> 80/8080 just from the console - and no default password.
> 
> There will be no access to the webinterface unless a password has been
> set from console.
> But we should allow to add users/passwords later from webconf.
> 
>> Here is my idea of securing the system
>>
>> - If someone gets near the console the system is compromised anyway.
>> No
>> security.
>> - I do not allow ssh with passwords, only ssh keys.
>> - I only allow https access and that typically only from the local
>> zone,
>> maybe even restrict it to single ip addresses.
>> - I _never_ allow web access without a password.
> 
> 
> All good advices - and some or all of them should be considered as
> improvements when installing the first time. But one step after
> another. 
> 
>> The problem with the current lighttpd config stems from the
>> observation
>> that the current method does not work, neither an empty password
>> field
>> nor a missing .htpasswd. So the router cannot be reached using the
>> web
>> interface with the current settings. The proposed change allows
>> access
>> with no security, just like your suggested interface would.
> 
> Yes but this has to be changed.
> Security is a feature not a bug. And while we are trying hard to make
> upgrades as seamless as possible, IMHO there are times when improving
> security is more important than user experience.
> I guess we both agree here in general, question is, if this is one
> these times - I'd say yes.

I slightly disagree, security is not a feature it is a _must_.
I agree using an empty or predefined password is bad.
I disagree of omitting .htpasswd for the reason of not being able to
save it later.

> 
>>>
>>>
>>> In step 2 we should force to use https instead of http to access
>>> the
>>> router.
>>
>> This is easy but requires a certificate. Do you want to provide one?
>> Any
>> certificate is better than none.
> 
> Really?

Yes, as it allows encrypted communication, e.g. https

> I mean I haven't thought about it and need some further reading.
> If that is a good idea, why not?
>  
> But if we agree to set the password during installation and get that
> done, creating certificate shouldn't be hard as well. Maybe a more
> comprehensive solution...?

I have not looked into the code at first installation as I disallow
password authentication on ssh anyway.

I _believe_ it is somewhere in .profile

#RPW=`grep root /etc/shadow | sed 's/root://' | sed 's/:.*//'`
#if test -z $RPW; then passwd; fi

and it is only true for root :-( , so no real security

You can see it is commented out in my case :-(

cheers

ET

Re: [leaf-devel] test, please discard

[KP K. <ka...@us...>]

On Do, 2018-02-15 at 14:32 +0000, Erich Titl wrote:
> Just a test

This one arrived; but another test (this one) is required...
sorry kp

> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] function test, please disregard

[Erich T. <eri...@th...>]

Just a test to see if SF is up again

Sorry for the noise

Re: [leaf-devel] lighttpd with empty password

[KP K. <ka...@us...>]

(resent, first try ended in SF outage)

Hi Erich;

On Di, 2018-02-13 at 19:14 +0000, Erich Titl wrote:
> Hi KP
> 
> Am 13.02.2018 um 18:10 schrieb KP Kirchdoerfer via leaf-devel:
> > Hi Erich;
> > On Di, 2018-02-13 at 13:31 +0000, Erich Titl wrote:
> > > Hi
> > > 
> > > Here a possible solution for the distribution of webconf with an
> > > empty
> > > passsword.
> > > 
> > > leaftester# more .htpasswd
> > > admin:2Dp46HA3ULDxA
> > > 
> > > This password has been created using
> > > 
> > > pwcrypt ""
> > > 
> > 
> > Been there done that, it doesn't work.
> 
> It does work, please state your observation.

Technically it works, but one don't even has to change the password to
get full access, so it's worse than before where we have had an
insecure web access, but at least the user was forced to change the
default (empty) password to continue.

> > 
> > The previous behaviour with mini_httpd was with an empty password
> > it
> > does not show anything unless you add a password after login as
> > admin -
> > it always pointed to passwd.cgi regradless what link you wanted to
> > open
> > in webconf.
> > Though everyone able to connect was able to login and change the
> > password and get acccess to the router.
> > 
> > This is in reality an illusion of security.
> 
> This is not an illusion of security, this is no security, but
> this is the way you can login with lighttpd and admin without knowing
> a
> password, as this is just the empty password.
> 
> - You _cannot_ login using lighttpd _and_ a missing .htpasswd right
> now.
> - You _cannot_ login using lighttpd _and_ an empty password field in
> .htpasswd right now.
> 
> So user access is broken, this method gives you a chance to login and
> _change_ the password to your own discretion. You will not be able to
> do
> that with the current empty password field.

True.

> > 
> > With lighttpd a really empty password in .htpasswd does not allow
> > any
> > login.
> 
> Yes it does not, but with a encrypted empty password it does.


> > 
> > The approach above allows to login with an empty password, but as
> > you
> > have a password, even an empty one, you have full access. Worse
> > than
> > before - and no better than having an open router without any
> > protection.
> 
> I don't get your idea. This enables the user to do _something_ just
> like
> before. With the current setttings the user is left alone.

We've learned (at least I have learned the last days) either way
(previous and with your patch) is without any real security as long as
you install webconf (esp if opened to WAN e.g. by accident).


> > 
> > Commercial routers often uses a default password, like "1234" for a
> > device I've installed recently in modem-mode before the LEAF router
> > and
> > you shall change it, but it works also without any changes. 
> > 
> > I think we can do better.
> 
> Commercial routers do exactly that and I agree it is bad. Now with
> lighttpd being a bit more restrictive than mhttpd(s) when it comes to
> .htpasswd we are in a small impasse.
> 
> > 
> > We should get rid of any mimic to allow access from anywhere
> > without a
> > proper password choosen by the user.
> 
> Do it with a script when starting a newly installed LEAF, that is
> fine.
> Do it with a post_install script in upgrade.
> 
> But what about users choosing to manually upgrade like Timothy?


1) Do not provide any .htpasswd with webconf, but take to save it, once
it is set (-> webconf buildtool.cfg needs to be changed)

2) try to add a script for first install if webconf but no .htpassswd
create one during installation like root password - if the user chooses
an empty one here so be it.

3) Users with a .htpasswd, hopefully changed password in the past, and
it won't be acffected when upgrading, because there is no default
.httpasswd any longer.

4) the same counts for upgrades with upgrade tool, so I do not see a
need for adding a script in post_upgrade

5) 1 to 4 needs to tested.


> > 
> > So the "problems" seen with the change to lighttpd are a benefit in
> > hindsight.
> 
> ??????

I've never thouht a lot about webconf login cause I don't use it. The
report on leaf-user changed that.

> > 
> > I tend to go the way:
> > 
> > - no access to webconf without a real password as default
> 
> Choose one, then publish it like the commercial vendors :-) Nothing
> really new and not secure at all.

> > - it should be possible to change the web login password from the
> > webpage
> 
> This is a hen-egg problem with lighttpd. If you find another solution
> which is _secure_, welcome to the club.

Here I've been unclear - let's not set the first password from port
80/8080 just from the console - and no default password.

There will be no access to the webinterface unless a password has been
set from console.
But we should allow to add users/passwords later from webconf.

> Here is my idea of securing the system
> 
> - If someone gets near the console the system is compromised anyway.
> No
> security.
> - I do not allow ssh with passwords, only ssh keys.
> - I only allow https access and that typically only from the local
> zone,
> maybe even restrict it to single ip addresses.
> - I _never_ allow web access without a password.


All good advices - and some or all of them should be considered as
improvements when installing the first time. But one step after
another. 

> The problem with the current lighttpd config stems from the
> observation
> that the current method does not work, neither an empty password
> field
> nor a missing .htpasswd. So the router cannot be reached using the
> web
> interface with the current settings. The proposed change allows
> access
> with no security, just like your suggested interface would.

Yes but this has to be changed.
Security is a feature not a bug. And while we are trying hard to make
upgrades as seamless as possible, IMHO there are times when improving
security is more important than user experience.
I guess we both agree here in general, question is, if this is one
these times - I'd say yes.

> > 
> > 
> > In step 2 we should force to use https instead of http to access
> > the
> > router.
> 
> This is easy but requires a certificate. Do you want to provide one?
> Any
> certificate is better than none.

Really? 
I mean I haven't thought about it and need some further reading.
If that is a good idea, why not?
 
But if we agree to set the password during installation and get that
done, creating certificate shouldn't be hard as well. Maybe a more
comprehensive solution...?

regards kp

[leaf-devel] test, please discard

[Erich T. <eri...@th...>]

Just a test

Re: [leaf-devel] lighttpd with empty password

[Erich T. <eri...@th...>]

Hi KP

Am 13.02.2018 um 18:10 schrieb KP Kirchdoerfer via leaf-devel:
> Hi Erich;
> On Di, 2018-02-13 at 13:31 +0000, Erich Titl wrote:
>> Hi
>>
>> Here a possible solution for the distribution of webconf with an
>> empty
>> passsword.
>>
>> leaftester# more .htpasswd
>> admin:2Dp46HA3ULDxA
>>
>> This password has been created using
>>
>> pwcrypt ""
>>
> 
> Been there done that, it doesn't work.

It does work, please state your observation.

> 
> The previous behaviour with mini_httpd was with an empty password it
> does not show anything unless you add a password after login as admin -
> it always pointed to passwd.cgi regradless what link you wanted to open
> in webconf.
> Though everyone able to connect was able to login and change the
> password and get acccess to the router.
> 
> This is in reality an illusion of security.

This is not an illusion of security, this is no security, but
this is the way you can login with lighttpd and admin without knowing a
password, as this is just the empty password.

- You _cannot_ login using lighttpd _and_ a missing .htpasswd right now.
- You _cannot_ login using lighttpd _and_ an empty password field in
.htpasswd right now.

So user access is broken, this method gives you a chance to login and
_change_ the password to your own discretion. You will not be able to do
that with the current empty password field.

> 
> With lighttpd a really empty password in .htpasswd does not allow any
> login.

Yes it does not, but with a encrypted empty password it does.

> 
> The approach above allows to login with an empty password, but as you
> have a password, even an empty one, you have full access. Worse than
> before - and no better than having an open router without any
> protection.

I don't get your idea. This enables the user to do _something_ just like
before. With the current setttings the user is left alone.

> 
> Commercial routers often uses a default password, like "1234" for a
> device I've installed recently in modem-mode before the LEAF router and
> you shall change it, but it works also without any changes. 
> 
> I think we can do better.

Commercial routers do exactly that and I agree it is bad. Now with
lighttpd being a bit more restrictive than mhttpd(s) when it comes to
.htpasswd we are in a small impasse.

> 
> We should get rid of any mimic to allow access from anywhere without a
> proper password choosen by the user.
Do it with a script when starting a newly installed LEAF, that is fine.
Do it with a post_install script in upgrade.

But what about users choosing to manually upgrade like Timothy?

> 
> So the "problems" seen with the change to lighttpd are a benefit in
> hindsight.

??????

> 
> I tend to go the way:
> 
> - no access to webconf without a real password as default

Choose one, then publish it like the commercial vendors :-) Nothing
really new and not secure at all.

> - it should be possible to change the web login password from the
> webpage

This is a hen-egg problem with lighttpd. If you find another solution
which is _secure_, welcome to the club.

> 
> 
> During first a fresh install of LEAF Bering-uClibc the user is asked to
> set a root password, we shall enhancethat to add this password for web
> login as well.

As already said, I have no clue how many users do a fresh install at
all. I guess it is a minority.

> 
> If a user chooses to go without any password, so it will be empty for
> console, ssh and webconf access - I'm not sorry for those who go that
> way.

Well....

Here is my idea of securing the system

- If someone gets near the console the system is compromised anyway. No
security.
- I do not allow ssh with passwords, only ssh keys.
- I only allow https access and that typically only from the local zone,
maybe even restrict it to single ip addresses.
- I _never_ allow web access without a password.

The problem with the current lighttpd config stems from the observation
that the current method does not work, neither an empty password field
nor a missing .htpasswd. So the router cannot be reached using the web
interface with the current settings. The proposed change allows access
with no security, just like your suggested interface would.

> 
> 
> In step 2 we should force to use https instead of http to access the
> router.

This is easy but requires a certificate. Do you want to provide one? Any
certificate is better than none.

cheers

ET

Re: [leaf-devel] lighttpd with empty password

[KP K. <ka...@us...>]

Hi Erich;
On Di, 2018-02-13 at 13:31 +0000, Erich Titl wrote:
> Hi
> 
> Here a possible solution for the distribution of webconf with an
> empty
> passsword.
> 
> leaftester# more .htpasswd
> admin:2Dp46HA3ULDxA
> 
> This password has been created using
> 
> pwcrypt ""
> 

Been there done that, it doesn't work.

The previous behaviour with mini_httpd was with an empty password it
does not show anything unless you add a password after login as admin -
it always pointed to passwd.cgi regradless what link you wanted to open
in webconf.
Though everyone able to connect was able to login and change the
password and get acccess to the router.

This is in reality an illusion of security.

With lighttpd a really empty password in .htpasswd does not allow any
login.

The approach above allows to login with an empty password, but as you
have a password, even an empty one, you have full access. Worse than
before - and no better than having an open router without any
protection.

Commercial routers often uses a default password, like "1234" for a
device I've installed recently in modem-mode before the LEAF router and
you shall change it, but it works also without any changes. 

I think we can do better.

We should get rid of any mimic to allow access from anywhere without a
proper password choosen by the user.

So the "problems" seen with the change to lighttpd are a benefit in
hindsight.

I tend to go the way:

- no access to webconf without a real password as default
- it should be possible to change the web login password from the
webpage


During first a fresh install of LEAF Bering-uClibc the user is asked to
set a root password, we shall enhance that to add this password for web
login as well.

If a user chooses to go without any password, so it will be empty for
console, ssh and webconf access - I'm not sorry for those who go that
way.


In step 2 we should force to use https instead of http to access the
router.

kp

[leaf-devel] lighttpd with empty password

[Erich T. <eri...@th...>]

Hi

Here a possible solution for the distribution of webconf with an empty
passsword.

leaftester# more .htpasswd
admin:2Dp46HA3ULDxA

This password has been created using

pwcrypt ""

cheers

ET

[leaf-devel] branch next

[KP K. <ka...@us...>]

Hi all;


Andrew, thx for looking into branch next and fixing remaining failing
packages.

I'm currently in the process to build kernels - the latest kernel
update breaks our configs.

I hesitate to upgrade the 4.9 kernel beyond 4.9.72 because that one
breaks igmpproxy, essential at least for me :)
And I'm afraid kernel 4.14.13 will have the same problem, but we'll
see.

There has been a lot work for the kernel the past days - as you know
there are security flaws.

AFAIK the raspberry pi images aren't affected.
For i486/geode/i686/wrap I think the CPU architectures won't be
affected as well.

The x86_64 toolchain provides fixes for meltdown and soon some
protection for spectre.

For the latest it seems to be necessary to use an updated gcc (8.x or
eventually 7.3) so Andrews work will gain value.

That said, I'm not shure if the security issues meltdown and spectre
are really that important for our project. AFAIK one needs ways to
access the router and run the commands to compromise the router
locally.
A way to run malware is by javascripts from the browser - we do not
support that, or to run malware from a local account. Given that an
attacker is capable to attack CPU bugs from a local account, the router
is already compromised.
A third way are images run in the cloud, so it's not a good idea to run
LEAF in a cloud, but I believe this is a very academic discussion....

Anyway we should try to include the necessary fixes sooner or later,
better be safe than sorry - but not at the cost of breaking working
setups.

Opinions? Thoughts?


kp

[leaf-devel] Just a test for my mail server, please disregard

[Erich T. <eri...@th...>]

JUst a test

Re: [leaf-devel] bug in apkg -u merge

[Erich T. <eri...@th...>]

Hi KP

Am 22.11.2017 um 18:32 schrieb KP Kirchdoerfer via leaf-devel:
> HI all;
> 
> when I update a package with apkg -u [packagename] and choose M 
> "M ) Edit a merged version of the files"
> 
> the file permissions are not saved to the original ones.
> 
> I've tried with (yet unreleased package) lighthttpd where the
> permissions for 
> /etc/init.d/lighttpd
> 
> are set to 755 (-rwxr-xr-x) in the package. After running update and
> edit with M(erge) the permissions are  set to 644 (-rw-r--r--).
> 
> The M(erge) command shouldn't change the permissions.

It does not :-( it creates a new file with the user's file creation mask
settings, see man umask.

m|M)
        tmp=$TMP/$SESSIONID.tmp
        apkg.mergefile $1/$3 $2/$3 > $tmp
        sha1=$(sha1sum $tmp)
        $EDITOR $tmp
        if echo "$sha1" | sha1sum -c >/dev/null 2>&1; then
                rm $tmp
        else
                mv $tmp $2/$3
                break
        fi
        ;;


So the culprit is in apkg.merge which just pipes the output of
apkg.mergefile into a temporary file.

You could temporarily change umask to get the right permissions or use a
more sophisticated aproach to file creation by reading first the
attributes of the files to be merged. But then what will you do if they
differ?

For example:

mega@leafbuilder64:/tmp$ umask
0002
mega@leafbuilder64:/tmp$ > foo
mega@leafbuilder64:/tmp$ umask 0004
mega@leafbuilder64:/tmp$ > bar
mega@leafbuilder64:/tmp$ ls -l foo bar
-rw-rw--w- 1 mega mega 0 Nov 22 22:44 bar
-rw-rw-r-- 1 mega mega 0 Nov 22 22:44 foo

mega@leafbuilder64:/tmp$ stat --format %a  foo bar
664
662

The easiest and crudest way would be to just force the output file.

mega@leafbuilder64:/tmp$ chmod 755 foo
mega@leafbuilder64:/tmp$ stat --format %a foo
755

cheers

ET

[leaf-devel] bug in apkg -u merge

[KP K. <ka...@us...>]

HI all;

when I update a package with apkg -u [packagename] and choose M 
"M ) Edit a merged version of the files"

the file permissions are not saved to the original ones.

I've tried with (yet unreleased package) lighthttpd where the
permissions for 
/etc/init.d/lighttpd

are set to 755 (-rwxr-xr-x) in the package. After running update and
edit with M(erge) the permissions are  set to 644 (-rw-r--r--).

The M(erge) command shouldn't change the permissions.

Maybe someone has time to look into this small, but annoying issue?

thx kp

Re: [leaf-devel] WPA2 updating without a reboot

[Erich T. <eri...@th...>]

Hi KP

Am 19.10.2017 um 18:30 schrieb KP Kirchdoerfer via leaf-devel:
> On Do, 2017-10-19 at 16:09 +0200, Erich Titl wrote:
...

>>
> Erich; if we are missing a patch for wpa_supplicant pls try to re-add
> ASAP.
> 

I am not that sure, probabl a misinterpretation on my part.
wpasupplicant was replaced without the system being informed. It might
be OK on a clean restart but must be manually restarted in this case.

btw. I would vote for an emergency delivery of the two packages based on
6.0.6, e.g. make a branch 6.0.6-wpa2 in packages.

cheers

ET

Re: [leaf-devel] WPA2 updating without a reboot

[KP K. <ka...@us...>]

On Do, 2017-10-19 at 16:09 +0200, Erich Titl wrote:
> Hi Folks
> 
> You nay know that I was and will always be interested in ways to
> update
> my system in something like an open heart operation. I have never
> been
> too convinced that every replacement of a subsystem requires a
> reboot.
> 
> So today in the wake of the WPA2 bug...
> I just recompiled wpasupp and hostapd in maint and built packages for
> it. I copied the packages to the storage of the very Wifi router I am
> using to access the internet here in the marina, then updated the
> packages on the running system using apkg -u.
> 
> I restarted hostapd and after a few seconds it still acceppted my
> access
> to the system.
> 
> I then set wlan0 down and up again but wpasupplicant was not started
> automatically as I had expected because I had removed the
> wpa_supplicant_control line which would automagically start
> wpasupplicant when the interface comes up. I was hopinng my patch for
> wpa_supplicant init would have made it to the distributio, but
> whatever...
> 
Erich; if we are missing a patch for wpa_supplicant pls try to re-add
ASAP.

kp 

[leaf-devel] WPA2 updating without a reboot

[Erich T. <eri...@th...>]

Hi Folks

You nay know that I was and will always be interested in ways to update
my system in something like an open heart operation. I have never been
too convinced that every replacement of a subsystem requires a reboot.

So today in the wake of the WPA2 bug...
I just recompiled wpasupp and hostapd in maint and built packages for
it. I copied the packages to the storage of the very Wifi router I am
using to access the internet here in the marina, then updated the
packages on the running system using apkg -u.

I restarted hostapd and after a few seconds it still acceppted my access
to the system.

I then set wlan0 down and up again but wpasupplicant was not started
automatically as I had expected because I had removed the
wpa_supplicant_control line which would automagically start
wpasupplicant when the interface comes up. I was hopinng my patch for
wpa_supplicant init would have made it to the distributio, but whatever...

Anyway, starting wpa supplicant manually gave me internet access again
without rebooting the device and without physical access.

Of course I set the missing parameter in /etc/network/interfaces as
before but would emphasize the importance of starting wpasupplicant with
the interface as it is torn down at ifdown wlanx

cheers

ET

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit [a5de4c] by kapeka

[Erich T. <eri...@th...>]

Hi KP

Am 19.10.2017 um 15:04 schrieb KP Kirchdoerfer via leaf-devel:
> On Do, 2017-10-19 at 14:44 +0200, Erich Titl wrote:
>> Hi KP
>>
>> Am 19.10.2017 um 14:36 schrieb KP Kirchdoerfer via leaf-devel:
>>> Hi Erich;
>>>
>>> On Do, 2017-10-19 at 13:46 +0200, Erich Titl wrote:
>>>> Hi KP
>>>>
>>>> is wpa-supplicant not affected? I was under the impression this
>>>> was
>>>> the
>>>> case.
>>>
>>> I'm working on it; pls doublecheck the commits (if available)
>>
>> Might be easier if we had hostapd in git as a subproject :-)
>>
> I understand what you refer to :)
> But I doubt this would have helped. The patches are the rebased ones
> for 2.6, a subproject would have all (unstable) commits for upcoming
> version.

Very unfortunate, I would have betted that Jouni would branch off
2.6-stable and apply the patches there. I guess he probably did and we
don't quite understand the git repository. But when it come to us I
despise to keep all those patches and tarballs and apply them at each
recompile. Why can't we just apply them once for good, keep the unpacked
source in the repo and use git to handle the diffs. If a new 2.7 pops up
then just switch branches e.t.c.

I believe this would make the build process a lot easier, but that is
another story.

cheers

ET

> 
> kp
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel
> 

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit [a5de4c] by kapeka

[KP K. <ka...@us...>]

On Do, 2017-10-19 at 14:44 +0200, Erich Titl wrote:
> Hi KP
> 
> Am 19.10.2017 um 14:36 schrieb KP Kirchdoerfer via leaf-devel:
> > Hi Erich;
> > 
> > On Do, 2017-10-19 at 13:46 +0200, Erich Titl wrote:
> > > Hi KP
> > > 
> > > is wpa-supplicant not affected? I was under the impression this
> > > was
> > > the
> > > case.
> > 
> > I'm working on it; pls doublecheck the commits (if available)
> 
> Might be easier if we had hostapd in git as a subproject :-)
> 
I understand what you refer to :)
But I doubt this would have helped. The patches are the rebased ones
for 2.6, a subproject would have all (unstable) commits for upcoming
version.

kp

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit [a5de4c] by kapeka

[Erich T. <eri...@th...>]

Hi KP

Am 19.10.2017 um 14:36 schrieb KP Kirchdoerfer via leaf-devel:
> Hi Erich;
> 
> On Do, 2017-10-19 at 13:46 +0200, Erich Titl wrote:
>> Hi KP
>>
>> is wpa-supplicant not affected? I was under the impression this was
>> the
>> case.
> 
> I'm working on it; pls doublecheck the commits (if available)

Might be easier if we had hostapd in git as a subproject :-)

cheers

ET

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit [a5de4c] by kapeka

[KP K. <ka...@us...>]

Hi Erich;

On Do, 2017-10-19 at 13:46 +0200, Erich Titl wrote:
> Hi KP
> 
> is wpa-supplicant not affected? I was under the impression this was
> the
> case.

I'm working on it; pls doublecheck the commits (if available)

https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-mes
sages.txt


kp

> 
> cheers
> 
> ET
> 
> -------- Weitergeleitete Nachricht --------
> Betreff: 	[leaf:bering-uclibc] New commit [a5de4c] by kapeka
> Datum: 	Thu, 19 Oct 2017 11:39:33 +0000
> Von: 	LEAF Linux Embedded Appliance Framework Git repository
> <no...@be...>
> Antwort an: 	LEAF Linux Embedded Appliance Framework Git
> repository
> <no...@be...>
> An: 	LEAF Linux Embedded Appliance Framework Git repository
> <no...@be...>
> 
> 
> 
>     Branch: maint
> 
> hostapd: add security fixes
> 
> Avoid key reinstallation in FT handshake
> Fix PTK rekeying to generate a new ANonce
> 
> By kapeka on 10/19/2017 11:33
> *View Changes*
> <https://sourceforge.net/p/leaf/bering-uclibc/ci/a5de4ca149500f36c878
> 60cf6eab80f707fedf64/>
> 
> -------------------------------------------------------------------
> -----
> 
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
> 
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
> 
> 
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> leaf-devel mailing list
> lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] Fwd: [leaf:bering-uclibc] New commit [a5de4c] by kapeka

[Erich T. <eri...@th...>]

Hi KP

is wpa-supplicant not affected? I was under the impression this was the
case.

cheers

ET

-------- Weitergeleitete Nachricht --------
Betreff: 	[leaf:bering-uclibc] New commit [a5de4c] by kapeka
Datum: 	Thu, 19 Oct 2017 11:39:33 +0000
Von: 	LEAF Linux Embedded Appliance Framework Git repository
<no...@be...>
Antwort an: 	LEAF Linux Embedded Appliance Framework Git repository
<no...@be...>
An: 	LEAF Linux Embedded Appliance Framework Git repository
<no...@be...>



    Branch: maint

hostapd: add security fixes

Avoid key reinstallation in FT handshake
Fix PTK rekeying to generate a new ANonce

By kapeka on 10/19/2017 11:33
*View Changes*
<https://sourceforge.net/p/leaf/bering-uclibc/ci/a5de4ca149500f36c87860cf6eab80f707fedf64/>

------------------------------------------------------------------------

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/leaf/bering-uclibc/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/