maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Competitors (https://talk.maemo.org/forumdisplay.php?f=4)
-   -   Android kernel: revealed 359 software defects (https://talk.maemo.org/showthread.php?t=65035)

PMaff 2010-11-04 09:55
Android kernel: revealed 359 software defects
 
Interesting:
"# The Android kernel tested by Coverity revealed 359 software defects, which is a sample of what might be shipping in popular mobile and other Android-based devices.
# 25 percent of the Android defects found are high risk with the potential to cause security breaches and crashes."

http://www.coverity.com/html/press/c...n-android.html

I wanted to say "I know why I do not use Android" ;-) but otoh:
do we have such analyses for Maemo?

Matan 2010-11-04 10:04
Re: Android kernel: revealed 359 software defects
 
The android kernel is Linux kernel, probably most of those "defects" are in Maemo as well.

And defining a flaw that can give a user root access as "high risk" on a single user machine, where user can do practically anything, including sending all your private data anywhere and cost you any sum in fees and the only addition thing root can do is to require a 5 minutes reflash of the system, is nothing but a cheap publicity stunt.

lma 2010-11-04 10:38
Re: Android kernel: revealed 359 software defects
 
Quote:
Originally Posted by Matan (Post 863049)
The android kernel is Linux kernel, probably most of those "defects" are in Maemo as well.
Indeed, it might be interesting to know what percentage of these also apply to vanilla 2.6.32 and how many of those have since been fixed in Linus's tree but ignored downstream.

Quote:
the only addition thing root can do is to require a 5 minutes reflash of the system, is nothing but a cheap publicity stunt.
Root in the wrong hands can be a bit more destructive than that, eg overwrite the NOLO mtd partition (requiring a roundtrip to a Nokia service centre at least), pin the CPU clock as high as possible (potentially killing the chip via overheating), or mess with the charging logic (potential for things going boom).

noobmonkey 2010-11-04 11:07
Re: Android kernel: revealed 359 software defects
 
I'm waiting for the attack of desktop sheep roaming around on the n900 - like on windows in the 90's.... oh the joys :) (Process killer, but genius to watch as the single sheep multiplies into 10,000 and windows topples over!)

kureyon 2010-11-04 17:08
Re: Android kernel: revealed 359 software defects
 
Quote:
Originally Posted by PMaff (Post 863036)
I wanted to say "I know why I do not use Android" ;-) but otoh:
do we have such analyses for Maemo?
Report also says
Quote:
"The Coverity Scan results for the Android kernel we tested show a better than average defect density, meaning this specific kernel is shipping with fewer defects than the industry average for software of this size,"

javispedro 2010-11-04 17:21
Re: Android kernel: revealed 359 software defects
 
Not to mention that you cannot, theoretically, declare any potential NULL dereference pointer found in a static analysis of source code a "security issue". At most, it is a potential one.

microe 2010-11-04 17:37
Re: Android kernel: revealed 359 software defects
 
> At most, it is a potential one.

Never, ever marginalize the effect of an invalid pointer in kernel space.

microe 2010-11-04 17:41
Re: Android kernel: revealed 359 software defects
 
Quote:
Originally Posted by Matan (Post 863049)
And defining a flaw that can give a user root access as "high risk" on a single user machine, where user can do practically anything, including sending all your private data anywhere and cost you any sum in fees and the only addition thing root can do is to require a 5 minutes reflash of the system, is nothing but a cheap publicity stunt.
Since the last DEFCON showed off an Android remote exploit that only required a minimal amount of user input and a way to create one's own cell that piggy-backs the actual cell, I wouldn't call this a publicity stunt. And coverity ain't cheap ;)

PMaff 2010-11-04 18:17
Re: Android kernel: revealed 359 software defects
 
Quote:
Originally Posted by javispedro (Post 863454)
Not to mention that you cannot, theoretically, declare any potential NULL dereference pointer found in a static analysis of source code a "security issue". At most, it is a potential one.
If it is one of the kind x->y=something where x is NULL (for whatever reason) I would say this is an issue anyway.
:D

javispedro 2010-11-04 18:21
Re: Android kernel: revealed 359 software defects
 
Quote:
Originally Posted by microe (Post 863465)
> At most, it is a potential one.

Never, ever marginalize the effect of an invalid pointer in kernel space.
I do marginalize the effectiveness of a static analysis code tool for detecting such issues.
Code:
struct some_interface *c = get_from_global_variable();
some_callback_type f = default_callback();

if (c->do_something(c, &f)) {
  f();
}
What's a static code analysis tool doing to do here? It may
a ) Either detect a "potential NULL dereference", thus indicating that the 5000000 potential bugs found count is pure crap.
b) Do nothing. I do not know which one is worse!
c) Somehow magically deduce all posible code paths and follow them all to detect where the actual bug is. The list of all available code paths does not only depend on hardware configuration but might actually even depend on the current time.

Not to mention the above is a pretty common idiom, specially if, as according to the makers of this tool themselves, "dereferencing function pointers is quite common on the kernel".

Quote:
Since the last DEFCON showed off an Android remote exploit that only required a minimal amount of user input and a way to create one's own cell that piggy-backs the actual cell, I wouldn't call this a publicity stunt. And coverity ain't cheap
I do not see why a local root exploit would have help here. Specially one where you to exploit you need to get to usually sandbox forbidden functionality such as mmap().

Now on Maemo getting root is usually as easy as running any of the numerous setuid binaries or sudoers-listed programs, so I can understand why it doesn't matter. On other platforms, maybe that's not true. On WebOS at least, _every application_ already runs as root by default, and there was no normal user at all until a recent version.

Now, of course their tools ain't cheap. They're doing a great service to the community IMHO but also getting some free marketing for a tool a decade or two ago would be laughed at.

Note: not saying it is useless; it's as useless as getting a human to do it: they might get it wrong, but "the more eyes...".

ndi 2010-11-04 19:41
Re: Android kernel: revealed 359 software defects
 
Quote:
Originally Posted by lma (Post 863070)
or mess with the charging logic (potential for things going boom).
Not likely, the battery itself is load limited, overcharge protected, undercharge protected and thermal limited, as are all Lithium batteries meant for (high-end) consumers.

If it weren't, it would go boom if the phone got stuck in an infinite loop: high drain, software dead, overheat > boom. The battery cuts power by itself if it's worth any of that 1000% markup Nokia puts on it.

The scenario you proposed would be indeed valid if Nokia used an enthusiast/modeling battery - those are only limited in amps - sometimes not even that. IIRC, they don't even make them in the same form factor.

microe 2010-11-04 20:43
Re: Android kernel: revealed 359 software defects
 
Quote:
Originally Posted by javispedro (Post 863507)
I do marginalize the effectiveness of a static analysis code tool for detecting such issues.
FWIW, Coverity does a very good job on showing only real invalid pointer defects (or real defects of any type for that matter). If you have experience w/ the tool, I am surprised that you would still have that opinion.

PMaff 2010-11-04 21:17
Re: Android kernel: revealed 359 software defects
 
Quote:
Originally Posted by javispedro (Post 863507)
I do marginalize the effectiveness of a static analysis code tool for detecting such issues.
Code:
struct some_interface *c = get_from_global_variable();
some_callback_type f = default_callback();

if (c->do_something(c, &f)) {
  f();
}
I would ask why there is no
check for c and f at first.
;-)
Plain defensive programming.


Quote:
Originally Posted by javispedro (Post 863507)
What's a static code analysis tool doing to do here? It may
a ) Either detect a "potential NULL dereference", thus indicating that the 5000000 potential bugs found count is pure crap.
It will find this:
http://scan.coverity.com/report/Cove...eport_2009.pdf
and there the stuff about
"In drivers/net/tun.c, the relevant code fragment is
static unsigned int tun_chr_poll(struct file *file, poll_table * wait)"


Quote:
Originally Posted by javispedro (Post 863507)
Now, of course their tools ain't cheap. They're doing a great service to the community IMHO but also getting some free marketing for a tool a decade or two ago would be laughed at.

Note: not saying it is useless; it's as useless as getting a human to do it: they might get it wrong, but "the more eyes...".
You know that sometimes when you look at your code over and over again you simply miss certain points.
Especially after long nights, much coffee and pizza.
;)

javispedro 2010-11-04 21:46
Re: Android kernel: revealed 359 software defects
 
Quote:
Originally Posted by microe (Post 863630)
FWIW, Coverity does a very good job on showing only real invalid pointer defects (or real defects of any type for that matter). If you have experience w/ the tool, I am surprised that you would still have that opinion.
I have no doubt it makes the best good job it could do. The problem is that it is theoretically impossible for it to do the perfect job. I have no experience with Coverity, but I do have some experience in compiler design.

Only in an insane world 359 "potential" null dereferences implies 359 software defects, and only in an even more insane world 359 software defects imply 359 CRITICAL security issues.

Quote:
Originally Posted by PMaff (Post 863673)
I would ask why there is no
check for c and f at first.
;-)
Plain defensive programming.
Ah, a Java user! ;) Do you know that GCC has both a always-check-for-nulls-before-first-deference and a array bounds checking patch? I leave as an exercise to the reader why Linux doesn't use them.

Quote:
You know that sometimes when you look at your code over and over again you simply miss certain points.
Especially after long nights, much coffee and pizza.
;)
And I agree, as I said: the more eyes the better.


All times are GMT. The time now is 15:59.

vBulletin® Version 3.8.8