Reply
Thread Tools
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#21
Bug fixes:

Android Support:

Fixed an issue where System UI has stopped while running Android app
Improved restart handling for Android runtime
Support for lockscreen media controls
SMS sending support
Then again, thanks to people requesting to incorporate android more into SFOS, premium SMS sending malwares should now work on jolla, not going to test it, but it looks like the sandbox is more and more likely to leak out (edit: hopefully next update will bring back option to seal pandora's box like having the option to not share contacts with the android part, didn't see any comments about this being optional)

Last edited by szopin; 2016-01-19 at 18:54.
 

The Following 2 Users Say Thank You to szopin For This Useful Post:
Posts: 245 | Thanked: 233 times | Joined on May 2010 @ Ljubljana, Slovenia
#22
Originally Posted by szopin View Post
Then again, thanks to people requesting to incorporate android more into SFOS, premium SMS sending malwares should now work on jolla, not going to test it, but it looks like the sandbox is more and more likely to leak out (edit: hopefully next update will bring back option to seal pandora's box like having the option to not share contacts with the android part, didn't see any comments about this being optional)
2.0.1.7 has an option under android support to limit access to contacts.
 

The Following 2 Users Say Thank You to sponka For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#23
Originally Posted by sponka View Post
2.0.1.7 has an option under android support to limit access to contacts.
Sorry, must've been unclear, meant exactly this, contacts sharing with AD has been optional from start, giving android access to telephony functions (premium SMS sending for example) doesn't seem to be integrated this way. The sandboxed android is becoming more and more able to interact with non-android part, without letting user choose which part they are fine with (release notes also mentioned SD card access, but one place mentions android access to SD card, the other option to format card from settings, so not sure about this one)
 

The Following User Says Thank You to szopin For This Useful Post:
Posts: 205 | Thanked: 389 times | Joined on Nov 2009
#24
Originally Posted by szopin View Post
Except it is all in chroot, so uninstall aliendalvik and it will be gone, the described situation of reflashing/resetting device to be still malwared should not be possible (sure there might be other exploits, but then it will be using some generic linux bugs/0days on top of android exploits that have to work in the emulated form, there definitely are holes, but you have two layers to get through)

Sorry, I was referring to NATIVE applications on Sailfish. We don't grant permissions or such like Android. We have no malware yet as far as I know probably because there are so few users so the target is too small to bother with. My **guess** is it might be easier to write malware for Sailfish due to the lack of any security model.
 

The Following 2 Users Say Thank You to salyavin For This Useful Post:
Posts: 1,873 | Thanked: 4,529 times | Joined on Mar 2010 @ North Potomac MD
#25
I guess some people here might argue that Android is malware in itself...
 

The Following 4 Users Say Thank You to mscion For This Useful Post:
Posts: 1,424 | Thanked: 2,623 times | Joined on Jan 2011 @ Touring
#26
Originally Posted by mscion View Post
I guess some people here might argue that Android is malware in itself...
Once they mainline the android kernel it will make building linux distros for droid hardware easier, but we will still be stuck with scary bin blob drivers which could be doing anything and are pre-compiled for only one kernel version.
 

The Following 4 Users Say Thank You to biketool For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#27
Originally Posted by salyavin View Post
Sorry, I was referring to NATIVE applications on Sailfish. We don't grant permissions or such like Android. We have no malware yet as far as I know probably because there are so few users so the target is too small to bother with. My **guess** is it might be easier to write malware for Sailfish due to the lack of any security model.
No idea what tools harbour uses, but seeing how they limit APIs and supposedly review apps it should give a bit of security (then again workarounds for apps needing to get root are plenty in warehouse and harbour accepts closed source apps, would be interesting to learn more about their processes). Wonder what happened to these guys http://talk.maemo.org/showthread.php?t=94116 their presentation on SFOS security was never uploaded to their vimeo channel, hopefully Jolla did their part to address whatever they found and eko guys just forgotten they can upload it now and are not still waiting for Jolla to give them greenlight after fixing the 0days
 

The Following 2 Users Say Thank You to szopin For This Useful Post:
Posts: 207 | Thanked: 552 times | Joined on Jul 2011
#28
Originally Posted by szopin View Post
Wow, that is pretty effedup, the droids are so secure that you can't even fix them when malware hits you. Where's the outrage?
Oh, I've got an abundance of that right now

Originally Posted by biketool View Post
Once they mainline the android kernel it will make building linux distros for droid hardware easier, but we will still be stuck with scary bin blob drivers which could be doing anything and are pre-compiled for only one kernel version.
I hope Google's contributions will be thoroughly audited!


If anyone from Jolla reads this please take note, here's some Android crapola Sailfish really needs to avoid:

When I uninstall an app I don't expect any app or service to be allowed to reinstall it

When I cancel an install dialog I expect that decision to be final, I don't want the dialog to be allowed to reappear and ask me again one second later over and over and over

If I'm using a system screen (e.g. settings) no background app should be allowed to bring up a modal image/dialog over the top of it

When I turn the wifi (gps/bt/...) off in settings no app should be allowed to turn it back on again without my explicit approval (and, as above, if I say no don't ask again)

Really, I could go on and on...


Honestly, there's so much m0r0n1c shite in Android I wonder if the chumps who developed it have any experience of the outside world.
 

The Following 2 Users Say Thank You to switch-hitter For This Useful Post:
Posts: 432 | Thanked: 917 times | Joined on Jun 2011
#29
Interesting times when even a android malware removal question turns into a SFOS security discussion...
 

The Following 5 Users Say Thank You to saponga For This Useful Post:
Posts: 207 | Thanked: 552 times | Joined on Jul 2011
#30
Hudl is alive

I installed Eset from the Play store, after installing I tried turning off the wifi but each time I turned it off the malware turned it on again so I used my router to block the MAC id of the Hudl. That immediately subdued many of the pop up ads that had been bombarding me but I was still getting lots of install dialogs for 'porn hub', 'sexy girls', etc... popping up repeatedly.

I performed a scan (all the while dismissing more install dialogs). Although Eset failed to kill off the malware it did create a log of all the problems it had identified.

I went into Settings->Apps->All and pressed 'Force Stop' and 'Disable' for all the items Eset had listed and some others that looked like they weren't from Google. That killed off the bombardment of install dialogs.

I then went back to the router and allowed the Hudl back on the network, went to settings and checked the box to allow install of apps from sources other than the play store and then downloaded and installed Kingo Root from download.com.

Not only did Kingo Root successfully root the Hudl but it has a SuperUser feature that allows you to delete apps and services. I went through the log from Eset and used SuperUser to delete all that I could. There were three items that even SuperUser could not uninstall but so far they have remained disabled even after reboots. The Hudl is now running fine and Eset is not reporting any threats.
 

The Following 7 Users Say Thank You to switch-hitter For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 02:35.