Topics

Master Thesis: Intentionally vulnerable infotainment system built on AGL #automotive #help


acsjakub@...
 

Dear AGL Community,

My name is Jakub and I plan to create a intentionally vulnerable infotainment system for demonstration purposes as my master's thesis. I will be using Raspberry Pi4 as hardware. Let me first point out that the vulnerabilities I plan to create and showcase will not be AGL-specific. My plan is to take a stable AGL version, develop/modify a couple of applications to make them vulnerable to the most common automotive security threats. These applications should be graphical, since the main purpose is demonstration. 

I have spent past two weeks trying to get familiar with AGL and associated technologies, deployed a demo image to RPi4, installed standalone SDK and built a helloworld .wgt, which I failed to run so far. However, I am struggling to find any documentation on how to write, build and deploy graphical applications for AGL, how to make them work with the homescreen and so on. There's a big chance I am missing something fundamental, so in my first ask for help, I'd like to ask you if you could point me out on the resources that I just described I am after.

Any help is greatly appreciated,

Kind Regards,
Jakub Acs


ilies bogdan
 

Hi Jakub,

There are already a few demo apps which you can use either as an example on how to write new graphical apps (e.g https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/hvac.git;a=summary) or fork them and use for your purpose. 

Regards,
Bogdan Ilies


On Sun, 18 Oct 2020 at 20:45, acsjakub@...
<acsjakub@...> wrote:
Dear AGL Community,

My name is Jakub and I plan to create a intentionally vulnerable infotainment system for demonstration purposes as my master's thesis. I will be using Raspberry Pi4 as hardware. Let me first point out that the vulnerabilities I plan to create and showcase will not be AGL-specific. My plan is to take a stable AGL version, develop/modify a couple of applications to make them vulnerable to the most common automotive security threats. These applications should be graphical, since the main purpose is demonstration. 

I have spent past two weeks trying to get familiar with AGL and associated technologies, deployed a demo image to RPi4, installed standalone SDK and built a helloworld .wgt, which I failed to run so far. However, I am struggling to find any documentation on how to write, build and deploy graphical applications for AGL, how to make them work with the homescreen and so on. There's a big chance I am missing something fundamental, so in my first ask for help, I'd like to ask you if you could point me out on the resources that I just described I am after.

Any help is greatly appreciated,

Kind Regards,
Jakub Acs


Marius Vlad
 

On Sun, Oct 18, 2020 at 11:45:41AM -0700, acsjakub@... wrote:
Dear AGL Community,
Hi,

My name is Jakub and I plan to create a intentionally vulnerable
infotainment system for demonstration purposes as my master's thesis.
I will be using Raspberry Pi4 as hardware. Let me first point out that
the vulnerabilities I plan to create and showcase will not be
AGL-specific. My plan is to take a stable AGL version, develop/modify
To some extent they will be AGL-specific. We make use a framework [1]
that handles application privileges and we use a LSM module [2] to handle
security at a global level.
a couple of applications to make them vulnerable to the most common
automotive security threats. These applications should be graphical,
since the main purpose is demonstration.
Why? There are multiple parts in (infotainment) system, you can leverage
one against the other and escalate, or rather chain-load various
exploits -- which I believe is common/necessary to bypass mitigations.
If the purpose is to focus on the graphics system/sub-system, you need
to be aware that as opposed to X11, on wayland clients can not gain
access to other client's buffers. Also the demo platform/apps is a bit
more lax/permissive on purpose to allow easier development to happen, or
provide some functionality commonly found on other systems
(for instance, screenshooting, or the allow-all policy in the compositor).

I have spent past two weeks trying to get familiar with AGL and
associated technologies, deployed a demo image to RPi4, installed
standalone SDK and built a helloworld .wgt, which I failed to run so
far. However, I am struggling to find any documentation on how to
write, build and deploy graphical applications for AGL, how to make
them work with the homescreen and so on. There's a big chance I am
Have you've taken a look some of the demo apps? Like
mediaplayer/hvac/dashboard/alexa-viewer? Some of these to not need any
additional 'graphical' interaction aside from what the toolkit (Qt)
provides. I mean, there's nothing special needed to be done. Yes, there
are cases where that might not be the case and you still some additional
support. Would suggest going over [3], if you would like to find out
more about that.

Deployment varies depending on you build, but it is going to be
something related to transferring your widget over the target board
using some kind of a networking tool (scp/nfs/ndb).

Also, have you taken a look at [4]? Some of that information might be
obsolete at this point, but nevertheless the workflow is the same. I
personally haven't used the SDK to create/builds application, rather I
use yocto/OE directly and scp to transfer it (the widget). I'm not
really sure, I guess the SDK should provide at least build tools
(cmake/qmake/meson) support. Maybe someone else can chime in if they
have more info on that matter. For system-type applications my
impression is that is always better to use yocto/OE, rather than
deploying packages, but that doesn't mean you can script your way
through.

missing something fundamental, so in my first ask for help, I'd like
to ask you if you could point me out on the resources that I just
described I am after.
[1] https://docs.automotivelinux.org/docs/en/master/devguides/reference/iotbzh2016/03-AGL-AppFW-Privileges-Management.pdf
[2] https://en.wikipedia.org/wiki/Smack_(software)
[3] https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/agl-compositor.git;a=blob_plain;f=doc/README.md;hb=HEAD
[4] https://docs.automotivelinux.org/docs/en/master/getting_started/reference/getting-started/app-workflow-intro.html

Any help is greatly appreciated,

Kind Regards,
Jakub Acs





acsjakub@...
 

HI Bogdan and Marius ,

Bogdan:
There are already a few demo apps which you can use either as an example on how to write new graphical apps (e.g https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/hvac.git;a=summary) or fork them and use for your purpose.
thank you for pointing me the right directions, I will definitely check these out! I must have missed them until now as I'm still learning to navigate through all the materials.

Marius:
To some extent they will be AGL-specific. We make use a framework [1]
that handles application privileges and we use a LSM module [2] to handle
security at a global level.
thank you, I am going to read [1] and [2] and make familiar with them and maybe come back with questions.
Why? There are multiple parts in (infotainment) system, you can leverage
one against the other and escalate, or rather chain-load various
exploits -- which I believe is common/necessary to bypass mitigations.
If the purpose is to focus on the graphics system/sub-system, you need
to be aware that as opposed to X11, on wayland clients can not gain
access to other client's buffers. Also the demo platform/apps is a bit
more lax/permissive on purpose to allow easier development to happen, or
provide some functionality commonly found on other systems
(for instance, screenshooting, or the allow-all policy in the compositor).
I'm sorry I probably wasn't very clear with this part. What I actually meant was that I want the applications to have a graphical user interface where the impact of the vulnerability can be presented to and understood by the non-technical audience, too. Not that the vulnerabilities will neccesarily have any graphical origin.

On demo being rather lax or permissive, thanks for pointing this out, I will have to discuss with my supervisor whether this is something we want to use to our advantage (it can simulate a misconfiguration problem) or whether we want to use fully-hardened image for the demonstration.
Have you've taken a look some of the demo apps? Like
mediaplayer/hvac/dashboard/alexa-viewer? Some of these to not need any
additional 'graphical' interaction aside from what the toolkit (Qt)
provides. I mean, there's nothing special needed to be done. Yes, there
are cases where that might not be the case and you still some additional
support. Would suggest going over [3], if you would like to find out
more about that.
This is the next on the list, thanks for pointing that out, I was struggling to find the source codes to be honest.

Deployment varies depending on you build, but it is going to be
something related to transferring your widget over the target board
using some kind of a networking tool (scp/nfs/ndb).

Also, have you taken a look at [4]? Some of that information might be
obsolete at this point, but nevertheless the workflow is the same. I
personally haven't used the SDK to create/builds application, rather I
use yocto/OE directly and scp to transfer it (the widget). I'm not
really sure, I guess the SDK should provide at least build tools
(cmake/qmake/meson) support. Maybe someone else can chime in if they
have more info on that matter. For system-type applications my
impression is that is always better to use yocto/OE, rather than
deploying packages, but that doesn't mean you can script your way
through.
yes, I was able to setup the xds as it was mentioned as a preferred way for development, I was also able to built using the standalone SDK as mentioned in the [4], however, I was wondering if these are still the preferred ways. Thank you for clarifying that. Also, I have no experience with yocto/OE, so that is another valuable piece of information there.

Overall, I am very grateful for your insight, and there's a lot of code reading and studying of what you mentioned in front of me, but this is generally what I was after, since I was drowning in the sea of different materials finding it hard to distinguish the relevant from the irrelevant.

To wrap up, thank you once more, I believe this has already been a huge help!

Kind regards,

Jakub Acs


Fulup Ar Foll
 

To get a good introduction on AGL security Module, you may check the training Jose gave last year at Brest University class https://iot.bzh/en/publications/38-2019/101-lesson-ensta-2019

On 19/10/2020 17:54, acsjakub@... wrote:
HI Bogdan and Marius ,

Bogdan:
There are already a few demo apps which you can use either as an example on how to write new graphical apps (e.g https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/hvac.git;a=summary) or fork them and use for your purpose.
thank you for pointing me the right directions, I will definitely check these out! I must have missed them until now as I'm still learning to navigate through all the materials.

Marius:
To some extent they will be AGL-specific. We make use a framework [1]
that handles application privileges and we use a LSM module [2] to handle
security at a global level.
thank you, I am going to read [1] and [2] and make familiar with them and maybe come back with questions.
Why? There are multiple parts in (infotainment) system, you can leverage one against the other and escalate, or rather chain-load various exploits -- which I believe is common/necessary to bypass mitigations. If the purpose is to focus on the graphics system/sub-system, you need to be aware that as opposed to X11, on wayland clients can not gain access to other client's buffers. Also the demo platform/apps is a bit more lax/permissive on purpose to allow easier development to happen, or provide some functionality commonly found on other systems (for instance, screenshooting, or the allow-all policy in the compositor).
I'm sorry I probably wasn't very clear with this part. What I actually meant was that I want the applications to have a graphical user interface where the impact of the vulnerability can be presented to and understood by the non-technical audience, too. Not that the vulnerabilities will neccesarily have any graphical origin.

On demo being rather lax or permissive, thanks for pointing this out, I will have to discuss with my supervisor whether this is something we want to use to our advantage (it can simulate a misconfiguration problem) or whether we want to use fully-hardened image for the demonstration.
Have you've taken a look some of the demo apps? Like mediaplayer/hvac/dashboard/alexa-viewer? Some of these to not need any additional 'graphical' interaction aside from what the toolkit (Qt) provides. I mean, there's nothing special needed to be done. Yes, there are cases where that might not be the case and you still some additional support. Would suggest going over [3], if you would like to find out more about that.
This is the next on the list, thanks for pointing that out, I was struggling to find the source codes to be honest.

Deployment varies depending on you build, but it is going to be something related to transferring your widget over the target board using some kind of a networking tool (scp/nfs/ndb). Also, have you taken a look at [4]? Some of that information might be obsolete at this point, but nevertheless the workflow is the same. I personally haven't used the SDK to create/builds application, rather I use yocto/OE directly and scp to transfer it (the widget). I'm not really sure, I guess the SDK should provide at least build tools (cmake/qmake/meson) support. Maybe someone else can chime in if they have more info on that matter. For system-type applications my impression is that is always better to use yocto/OE, rather than deploying packages, but that doesn't mean you can script your way through.
yes, I was able to setup the xds as it was mentioned as a preferred way for development, I was also able to built using the standalone SDK as mentioned in the [4], however, I was wondering if these are still the preferred ways. Thank you for clarifying that. Also, I have no experience with yocto/OE, so that is another valuable piece of information there.

Overall, I am very grateful for your insight, and there's a lot of code reading and studying of what you mentioned in front of me, but this is generally what I was after, since I was drowning in the sea of different materials finding it hard to distinguish the relevant from the irrelevant.

To wrap up, thank you once more, I believe this has already been a huge help!

Kind regards,

Jakub Acs