Re: [DNG] Beware the Icedove to Thunderbird transition

[marcus]

On 02/07/17 06:23 PM, Adam Borowski wrote:

On Sun, Jul 02, 2017 at 01:05:06PM -0400, Clark Sideroad wrote:

My advice: back-up everything related


Bad advice: just do the upgrade normally without any special precautions,
and if your special non-standard $Element$Bird setup gets borked, just
recover from backups you do anyway.  No special backup before an operation
as disruptive as upgrading between De??an releases is needed either, as you,
like anyone without a data loss wish, already backup at least daily.



You are right.
If I did as you say and I say and back up every day, I would be OK.

Then I could have done it again and again until I figured out the 
purpose of the .migrated file.


"This file is automatically created by /usr/bin/thunderbird, it will be
created on every start of Thunderbird if does not exist.
Remove that file only if you know the propose of this file."

In my case of stupidity the backup was a week old, the cat laughed too.
I probably should have added the .migrated file before I learned of it 
post script. (-;


--
Clarke
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware the Icedove to Thunderbird transition

[Adam Borowski]

On Sun, Jul 02, 2017 at 01:05:06PM -0400, Clark Sideroad wrote:
> My advice: back-up everything related

Bad advice: just do the upgrade normally without any special precautions,
and if your special non-standard $Element$Bird setup gets borked, just
recover from backups you do anyway.  No special backup before an operation
as disruptive as upgrading between De??an releases is needed either, as you,
like anyone without a data loss wish, already backup at least daily.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Rainer Weikusat]

Simon Hobson  writes:
> Arnt Gulbrandsen  wrote:
>
>> By now, the concept of unprivileged local users is a little obsolete anyway.
>> 
>> Today, hosts generally serve only one unix user, there generally is
>> only one local user of one host, and that local user is the user that
>> owns everything valuable. So is the a real point to
>> local-user-to-root exploits? I suppose there is, but it is much
>> smaller than it was ten or twenty years ago.
>
> It depends on what you are doing.
> It's a fairly quick and easy way to separate users on (eg) web hosting
> - by having Apache execute each site as a specific user.

[...]

> And regardless of how you separate users, having an exploitable
> privilege escalation flaw means that someone compromising one of your
> customer's sites is then able to escalate their privileges to do more
> damage than they could from an unprivileged account.

Hmm ... and how many 'millions of Android devices and Linux PCs' are
affected by that? This is a trivial bug with a one or two lines fix and
the people who found it could have spend their time in a more useful way
by contributing a fix then by creating and exploit and trying to draw as
much attention to that as possible.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[shraptor]

On 2016-01-19 23:07, Rainer Weikusat wrote:


You can find them in the System.map file for your kernel, eg,

...

Found it in my System.map


810a97d2 T prepare_kernel_cred
810a94b7 T commit_creds


Thanks for hint


some kind of stacksmashing?


No. The bug in the kernel function causes a reference to some object to

...

Thank you for that concise explanation, understanding a bit better now.

Entered the addresses from my kernel and ran the program.

It took 37 min to complete

$ ./cve_2016_0728 PP_KEY
uid=1000, euid=1000
Increfing...
finished increfing
forking...
finished forking
caling revoke...
uid=1000, euid=1000
$ id -u
1000
$ id -un
alpha


I am still not root at the end? Maybe a bit overestimated this bug?

I am on kernel 4.1.6

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Simon Hobson]

Arnt Gulbrandsen  wrote:

> By now, the concept of unprivileged local users is a little obsolete anyway.
> 
> Today, hosts generally serve only one unix user, there generally is only one 
> local user of one host, and that local user is the user that owns everything 
> valuable. So is the a real point to local-user-to-root exploits? I suppose 
> there is, but it is much smaller than it was ten or twenty years ago.

It depends on what you are doing.
It's a fairly quick and easy way to separate users on (eg) web hosting - by 
having Apache execute each site as a specific user. Yes I'm sure there are 
better and more secure ways of doing it, but when you inherit a setup where you 
have to trust each customer not to take a peek around other customer's sites 
(and grab their DB access credentials from the Wordpress config file) then it's 
a big step forwards !

And regardless of how you separate users, having an exploitable privilege 
escalation flaw means that someone compromising one of your customer's sites is 
then able to escalate their privileges to do more damage than they could from 
an unprivileged account.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Didier Kryn]

Le 19/01/2016 22:58, Stephanie Daugherty a écrit :


On Tue, Jan 19, 2016 at 4:12 PM, Arnt Karlsen > wrote:


..why did Debian kill ssh into localhost?
Is su or sudo safer than ssh nowadays?



Because the architecture of Linux gurantees that root has a fixed 
account name, fixed UID, and, if in a server environment, will be 
essentially a shared account, it's considered a long standing best 
practice to not let people log in directly as root, at least not 
remotely. This makes sure there's an audit trail of logging in with 
the unprivileged user and then elevating to root, rather than just the 
root login that doesn't indicate which of possibly several users was 
responsible. It also means a brute force against the root account is 
more difficult to automate, since you need to attack an umprivledged 
account first, and it offers a little bit of protection against a weak 
root password.


I guess you are talking of the default /etc/ssh/sshd_config. But it 
is the role of the (veteran) admin to edit this config file, and ssh 
provides a per address-range configuration. Therefiore it is very easy 
to allow root login from localhost, or even from the LAN, while 
forbidding it from other addresses.


man sshd_config says:

Match   Introduces a conditional block.  If all of the criteria on the
 Match line are satisfied, the keywords on the following lines
 override those set in the global section of the config file,
 until either another Match line or the end of the file.

 The arguments to Match are one or more criteria-pattern pairs.
 The available criteria are User, Group, Host, and 
Address.  The
 match patterns may consist of single entries or 
comma-separated
 lists and may use the wildcard and negation operators 
described

 in the PATTERNS section of ssh_config(5).

 The patterns in an Address criteria may additionally contain
 addresses to match in CIDR address/masklen format, e.g.
 “192.0.2.0/24” or “3ffe:::/32”.  Note that the mask length
 provided must be consistent with the address - it is an 
error to

 specify a mask length that is too long for the address or one
 with bits set in this host portion of the address.  For 
example,

 “192.0.2.0/33” and “192.0.2.0/8” respectively.

 Only a subset of keywords may be used on the lines following a
 Match keyword.  Available keywords are AllowAgentForwarding,
 AllowTcpForwarding, AuthorizedKeysFile, 
AuthorizedPrincipalsFile,

 Banner, ChrootDirectory, ForceCommand, GatewayPorts,
 GSSAPIAuthentication, HostbasedAuthentication,
 HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication,
 KerberosAuthentication, MaxAuthTries, MaxSessions,
 PasswordAuthentication, PermitEmptyPasswords, PermitOpen,
 PermitRootLogin, PermitTunnel, PubkeyAuthentication,
 RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset,
 X11Forwarding and X11UseLocalHost.




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Rainer Weikusat]

Rainer Weikusat  writes:
> shraptor  writes:
>> On 2016-01-19 19:07, Rainer Weikusat wrote:
>>> In this particular case, an unprivileged local user could gain root
>>> access by running a program which does billions of syscalls as fast as
>>> it can for ca 30 minutes (according the 'real' article).
>>
>> I tested the program in the 'real' article but it didn't work?
>>
>> But I guess you have to adjust addresses of commit_creds and
>> prepare_kernel_cred functions for my kernel version?
>> The article says they are static and can be determined per Linux
>> kernel version.
>>
>> How to determine those?
>
> You can find them in the System.map file for your kernel, eg,
>
> [rw@doppelsaurus]~#grep prepare_kernel_cred  /boot/System.map-4.4.0-net 

I meant to write this in a different context and then forgot about
it. The name has nothing to do with grab (or any other English word) but
before there was grep, the text editor could be used to accomlish the
same, eg,

[rw@doppelsaurus]~#ed /boot/System.map-4.4.0-net 
2095848
g/prepare_kernel_cred/p
810555f0 T prepare_kernel_cred
8179d680 R __ksymtab_prepare_kernel_cred
817acd40 r __kstrtab_prepare_kernel_cred
q

The first part of the ed command is an address whose meaning is 'for all
lines match re' (a regexp), the absract definition is

g/re/

'p' means 'print the addressed lines', hence,

g/re/p
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Rainer Weikusat]

shraptor  writes:
> On 2016-01-19 19:07, Rainer Weikusat wrote:
>> In this particular case, an unprivileged local user could gain root
>> access by running a program which does billions of syscalls as fast as
>> it can for ca 30 minutes (according the 'real' article).
>
> I tested the program in the 'real' article but it didn't work?
>
> But I guess you have to adjust addresses of commit_creds and
> prepare_kernel_cred functions for my kernel version?
> The article says they are static and can be determined per Linux
> kernel version.
>
> How to determine those?

You can find them in the System.map file for your kernel, eg,

[rw@doppelsaurus]~#grep prepare_kernel_cred  /boot/System.map-4.4.0-net 
810555f0 T prepare_kernel_cred
8179d680 R __ksymtab_prepare_kernel_cred
817acd40 r __kstrtab_prepare_kernel_cred

The T entry is the address of the function.

> some kind of stacksmashing?

No. The bug in the kernel function causes a reference to some object to
be leaked, ie, the reference count is incremented but not
decremented. This can be used to increment the count until the value
overflows to 0. The kernel will then free the object but without
invalidating the handle to it on the wrong presumption that since
refcount == 0, no handle exists anymore. These objects are allocated via
kmalloc which is a power-of-two freelist allocator. The implies that
it's possible to get the kernel to reuse the erroneously freed object
for 'something different' of a suitable size and users can copy
arbitrary data into the corresponding buffer. That used to create a
mock 'original object' with a function pointer value in it which points
to an application function accomplishing the privilege escalation. Since
the process still has a valid handle to the freed object, this handle
can be used to invoke a system call working with the user-supplied new
content of the corresponding memory area which then causes the kernel
to call the exploit function.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Stephanie Daugherty]

On Tue, Jan 19, 2016 at 4:12 PM, Arnt Karlsen  wrote:

> ..why did Debian kill ssh into localhost?
> Is su or sudo safer than ssh nowadays?
>


Because the architecture of Linux gurantees that root has a fixed account
name, fixed UID, and, if in a server environment, will be essentially a
shared account, it's considered a long standing best practice to not let
people log in directly as root, at least not remotely. This makes sure
there's an audit trail of logging in with the unprivileged user and then
elevating to root, rather than just the root login that doesn't indicate
which of possibly several users was responsible. It also means a brute
force against the root account is more difficult to automate, since you
need to attack an umprivledged account first, and it offers a little bit of
protection against a weak root password.

sudo is generally the accepted way in the ubuntu world as well as in most
server environments these days, since the audit trail will record exactly
what commands were elevated and by who, and since only a single command is
run with elevated permissions, therefore dropping back to an unprivledged
command prompt after each elevated command.

su was the best practice long before sudo or even Linux ever existed, and
is still perfectly acceptable for hobbyists, desktops, and others where
there's exactly one *competent* admin for each machine. and may even be a
viable option in other, more controlled environments that don't want to use
sudo. Historically, on other *nixes, it was gated with the "wheel" group,
(and this can be done on Linux as well if the admin wants to configure it
this way).

Obviously, this has the additional advantage that, through some tinkering
with PAM, you can implement additional authentication requirements just on
root access - for example, you might let your admins log in and look around
with just their SSH key, but require them to have an additional password or
multifactor authentication token to access root privileges.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Brian Nash]

On Tue, Jan 19, 2016 at 06:07:28PM +, Rainer Weikusat wrote:

"Linux kernel bug fixed" would be more appropriate.


Is this why I have never heard of any "antivirus" software for linux?
(Apart from clamav a while back...)

The users are capable of fixing the vulnerabilities themselves, so a
dedicated, cash-draining system such as Norton, and/or a cheap, sketchy
program such as McAfee are nearly irrelevant?

--
Shoot first and call whatever you hit the target.


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Arnt Karlsen]

On Tue, 19 Jan 2016 21:55:12 +0100, shraptor wrote in message 
<0f6f017d5d303a92526f829661e84...@epost.bahnhof.se>:

> On 2016-01-19 19:07, Rainer Weikusat wrote:
> > In this particular case, an unprivileged local user could gain root
> > access by running a program which does billions of syscalls as fast
> > as it can for ca 30 minutes (according the 'real' article).
> 
> I tested the program in the 'real' article but it didn't work?
> 
> But I guess you have to adjust addresses of commit_creds and 
> prepare_kernel_cred functions for my kernel version?
> The article says they are static and can be determined per Linux
> kernel version.
> 
> How to determine those? some kind of stacksmashing?

..recipe suggestions:
http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/
https://gist.github.com/PerceptionPointTeam/18b1e86d1c0f8531ff8f
https://phoronix.com/scan.php?page=news_item&px=Linux-Kernel-2016-0-Day
https://www.debian.org/security/2016/dsa-3448

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[karl]

Arnt Karlsen:
> On Tue, 19 Jan 2016 20:46:00 +, Rainer wrote in message 
> <87d1sxguwn@doppelsaurus.mobileactivedefense.com>:
> 
> > k...@aspodata.se writes:
> > > Arnt Gulbrandsen:
> > >> By now, the concept of unprivileged local users is a little
> > >> obsolete anyway.
> > >
> > > Yes, unless you let your kids or some guests use your computer.
> > 
> > How many of your "kids and guests" even know what a kernel is, let
> > alone how to exploit a bug in one?
> 
> ..systemd? ;oD

Ahh, the new kid on the block...

...
> ..why did Debian kill ssh into localhost?  
> Is su or sudo safer than ssh nowadays?

telnet or ssh localhost | tee log_file is useful for demonstrations.

Test this
 open two or more xterms (or similar), same size

 term 1: ssh localhost | tail trace

 term 2 and up: tail -f trace

and start working in term 1 (nothing graphical), eg emacs -nw 

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Arnt Karlsen]

On Tue, 19 Jan 2016 20:46:00 +, Rainer wrote in message 
<87d1sxguwn@doppelsaurus.mobileactivedefense.com>:

> k...@aspodata.se writes:
> > Arnt Gulbrandsen:
> >> By now, the concept of unprivileged local users is a little
> >> obsolete anyway.
> >
> > Yes, unless you let your kids or some guests use your computer.
> 
> How many of your "kids and guests" even know what a kernel is, let
> alone how to exploit a bug in one?

..systemd? ;oD

> >> Today, hosts generally serve only one unix user, there 
> >> generally is only one local user of one host, and that local user
> >> is the user that owns everything valuable. So is the a real point
> >> to local-user-to-root exploits? I suppose there is, but it is much
> >> smaller than it was ten or twenty years ago.
> >
> > The problem is not the local user == the owner, instead it is an 
> > unknown breaking in as a local user and then gaining root powers.
> 
> That's not going to be terribly difficult on a system I use as
> accounts I'm using usually can get root via sudo without entering a
> password. 

..why did Debian kill ssh into localhost?  
Is su or sudo safer than ssh nowadays?

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[shraptor]

On 2016-01-19 19:07, Rainer Weikusat wrote:

In this particular case, an unprivileged local user could gain root
access by running a program which does billions of syscalls as fast as
it can for ca 30 minutes (according the 'real' article).


I tested the program in the 'real' article but it didn't work?

But I guess you have to adjust addresses of commit_creds and 
prepare_kernel_cred functions for my kernel version?
The article says they are static and can be determined per Linux kernel 
version.


How to determine those? some kind of stacksmashing?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Rainer Weikusat]

k...@aspodata.se writes:
> Arnt Gulbrandsen:
>> By now, the concept of unprivileged local users is a little obsolete 
>> anyway.
>
> Yes, unless you let your kids or some guests use your computer.

How many of your "kids and guests" even know what a kernel is, let alone
how to exploit a bug in one?

>> Today, hosts generally serve only one unix user, there 
>> generally is only one local user of one host, and that local user is 
>> the user that owns everything valuable. So is the a real point to 
>> local-user-to-root exploits? I suppose there is, but it is much smaller 
>> than it was ten or twenty years ago.
>
> The problem is not the local user == the owner, instead it is an 
> unknown breaking in as a local user and then gaining root powers.

That's not going to be terribly difficult on a system I use as accounts
I'm using usually can get root via sudo without entering a password.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[karl]

Arnt Gulbrandsen:
> By now, the concept of unprivileged local users is a little obsolete 
> anyway.

Yes, unless you let your kids or some guests use your computer.

> Today, hosts generally serve only one unix user, there 
> generally is only one local user of one host, and that local user is 
> the user that owns everything valuable. So is the a real point to 
> local-user-to-root exploits? I suppose there is, but it is much smaller 
> than it was ten or twenty years ago.

The problem is not the local user == the owner, instead it is an 
unknown breaking in as a local user and then gaining root powers.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Arnt Gulbrandsen]

By now, the concept of unprivileged local users is a little obsolete 
anyway.


Today, hosts generally serve only one unix user, there 
generally is only one local user of one host, and that local user is 
the user that owns everything valuable. So is the a real point to 
local-user-to-root exploits? I suppose there is, but it is much smaller 
than it was ten or twenty years ago.


Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Rainer Weikusat]

Adam Borowski  writes:
> On Tue, Jan 19, 2016 at 04:09:10PM +, Rainer Weikusat wrote:
>> Steve Litt  writes:
>> > Beware:
>> >
>> > http://www.networkworld.com/article/3023447/security/linux-zero-day-affects-most-androids-millions-of-linux-pcs.html
>> 
>> Just another local privilege escalation. May enable users to gain
>> control of their own Android devices (imminent end of the world
>> predicted!) and affect setups where untrusted users are able to execute
>> arbitrary code as themselves.
>
> While rooting locked-down Androids is a good think, one shouldn't play down
> the severity of local exploits.

In this particular case, an unprivileged local user could gain root
access by running a program which does billions of syscalls as fast as
it can for ca 30 minutes (according the 'real' article).

And "affects most androids and millions of Linux PCs" is a way
overdramatized headline for that.

"Linux kernel bug fixed" would be more appropriate.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Rainer Weikusat]

shraptor  writes:
> On 2016-01-19 16:58, Steve Litt wrote:
>> Beware:
>>
>> http://www.networkworld.com/article/3023447/security/linux-zero-day-affects-most-androids-millions-of-linux-pcs.html
>
> Would this type of misbehavior be mitigated by kernel ASLR?

No.

It could be mitigated by 'uninventing' malloc as the idea to group
objects together based on their size (instead of their type) was never a
particularly good one but that's unlikely to happen.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[shraptor]

On 2016-01-19 16:58, Steve Litt wrote:

Beware:

http://www.networkworld.com/article/3023447/security/linux-zero-day-affects-most-androids-millions-of-linux-pcs.html


Would this type of misbehavior be mitigated by kernel ASLR?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Adam Borowski]

On Tue, Jan 19, 2016 at 04:09:10PM +, Rainer Weikusat wrote:
> Steve Litt  writes:
> > Beware:
> >
> > http://www.networkworld.com/article/3023447/security/linux-zero-day-affects-most-androids-millions-of-linux-pcs.html
> 
> Just another local privilege escalation. May enable users to gain
> control of their own Android devices (imminent end of the world
> predicted!) and affect setups where untrusted users are able to execute
> arbitrary code as themselves.

While rooting locked-down Androids is a good think, one shouldn't play down
the severity of local exploits.  While in a number of scenarios the game is
already lost without the attacker gaining root, they're not use cases.

But a kernel vulnerability differs from any other patched security issue
only by the need to reboot after "apt-get upgrade".

-- 
A tit a day keeps the vet away.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Mitt Green]

Does that actually mean that we should migrate
to newer kernels as soon as the hole gets fixed?

I reckon, even though there are plenty of
machines that run older than 3.8 (2.6.32 notably)
this affects pretty much everyone, at least here.

Well, applying patches is not something
time-consuming, but still.

Thanks for letting us know,
Mitt___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Rainer Weikusat]

Steve Litt  writes:
> Beware:
>
> http://www.networkworld.com/article/3023447/security/linux-zero-day-affects-most-androids-millions-of-linux-pcs.html

Just another local privilege escalation. May enable users to gain
control of their own Android devices (imminent end of the world
predicted!) and affect setups where untrusted users are able to execute
arbitrary code as themselves.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng