Sign up to save your podcasts
Or
Share Episode 185
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Episode 185
Overview
For our final episode of 2022, Camila is back with a special holiday themed
discussion of the security of open source code, plus we hint at what is in store
for the podcast for 2023 and we cover some recent security updates including
Python, PostgreSQL, Squid and more.
This week in Ubuntu Security Updates
54 unique CVEs addressed
[USN-5765-1] PostgreSQL vulnerability [00:55]
been established
[USN-5766-1] Heimdal vulnerability [01:38]
[USN-5768-1] GNU C Library vulnerabilities [01:47]
on untrusted input
[USN-5767-1, USN-5767-2] Python vulnerabilities [02:24]
applications - ie. unicode / bidirectional in your domain names) - used an
algorithm that was quadratic [O(n²)] - so if an attacker provided a really
long domain name that included crafted bidirectional unicode contents to be
parsed by the client, could cause the client to use lots of CPU resources to
parse this - this code was used by the socket and asyncio modules - and so
simply returning a 3xx redirect header with a crafted Location could trigger
this bug
true but this code was implemented in C
[USN-5769-1] protobuf vulnerabilities [03:56]
[USN-5770-1] GCC vulnerability
[USN-5771-1] Squid regression [04:05]
this was just a logging issue but turns out it was a real bug - an off-by-one
issue would mean squid would sometimes file to find items that were already
cached - only applies where the HTTP server is using the Vary header
[USN-5772-1] QEMU vulnerabilities [05:18]
[USN-5754-2, USN-5756-3] Linux kernel (Azure) vulnerabilities [05:39]
[USN-5754-1] Linux kernel
vulnerabilities - Buffer overflow in NFSD
[USN-5773-1] Linux kernel (OEM) vulnerabilities [06:14]
from GPZ discussed in the last 2 episodes
[USN-5774-1] Linux kernel (Azure) vulnerabilities [06:59]
[USN-5775-1] Vim vulnerabilities [07:18]
bounty program, found via fuzzing
[USN-5776-1] containerd vulnerabilities [08:07]
[USN-5777-1] Pillow vulnerabilities
Goings on in Ubuntu Security Community
Camila discusses the security of open source vs proprietary code [08:38]
Transcript
Hello listener! It has been a while since I last showed up here to share with
you some of my thoughts and spread the knowledge, and today I am back in order
to try to fix that, remove the void I have left in the hearts of those that
enjoy listening to me rambling about a certain cyber security topic. That being
said, I recorded my first podcast segment during the holiday season last year,
and I thought it would be very poetic to return at the same time this year to
record once again. Especially after I was struck with inspiration after spending
a little time with my family. Nothing more fitting for this once again holiday
episode, considering it is the time of the year - the most wonderful one - when
we usually enjoy mingling and celebrating with family and friends. The time of
the year where we meet in order to eat some good food, spend some quality time
together, catch up on life, share the joy… and answer the always asked
question by someone who knows you work with computers: “Do you think it’s a
virus?”. “Yes, uncle, it probably is, since the link you clicked on that said
‘Free 1000 dollar Christmas vouchers for the first 10 clicks’ is most likely a
scam. But hey, I gotta go now, because it is time for some delicious holiday
season desserts! Your computer can survive a few more hours doing some
cryptomining for some random hacker, so I’ll check on that later for you”.
Anyway, surprising as it may be, this actually was not the topic of conversation
that brought me here today, although I fully expect the previously mentioned
question to come my way whenever I do meet my family for the end of the year
festivities of 2022. Instead, I was asked a question that would probably have my
holiday treats wait for me a little bit longer, since it is one I find
compelling to answer, and one that I thought would be actually interesting to
share the answer to, so that you can take it to your holiday meetings as a hot
topic of conversation…you know…show off a little bit to the ones you love.
So…to elaborate a little bit more on my story and on this so far mysterious
question…while sipping on some delicious cocoa surrounded by some fairy lights
and the cold air - even though it is summer during the end of the year where I
live…I see you, southern hemisphere. I was traveling when this happened - my
dearest not-in-the-IT-field family member asked me the following question while
we had a conversation about my job: “how is it possible to have security in a
software when the code for that software is available for all to see on the
Internet?”. Running a prettify function on this question, we can word it as:
“how can open source software be secure if the code is public?”. And that,
family and friends, is the question that we wish to answer today. I already
answered my family member, but now, I want to do it the fancy way, the holiday
spirit way! So gather around with your drinks and delicious appetizers, and
before we head for dinner, and of course, dessert, let’s think about the year we
leave behind, the code that was a part of it, and why, in the year of 2022, can
this code be secure when everyone knows exactly what it is.
Let’s begin this beautiful holiday sharing moment by actually talking about what
is open source software and what is NOT open source software, as well as why one
would think that the former is less secure than the latter. To keep it simple:
open source software is the kind of software where the source code, a.k.a. the
instructions that will be transformed into the computer program that you will
later use, is publicly available for all to see. Those that wish to do so can
inspect this software’s code to know exactly how it does what it does. They can
use it freely if following its license terms, and they can even modify it, maybe
change its functionalities, be it through creation of a copy of that code that
branches from the original version, or be it with authorization from the
creator/maintainer of the software to edit the original version wherever it is
being maintained. A beautiful example to bring this all together in your mind:
almost all software packages in Ubuntu are open source. The programs you run in
your Ubuntu OS come from code that is publicly available for all to access
through the loveliest Internet. For many packages, it is possible to choose one
from main or universe, for example, and find its code in a repository after a
quick web search. Even quicker: you can download the source code related to the
executables and libraries apt installs in your Ubuntu OS when you run ‘apt-get
install ’ by running ‘apt-get source
’ instead. Please remember to replace
with the actual package name if you’re gonna try to
do this. Anyway, this package you download with apt may have its code differ a
little bit from the original code for that software package, the one maintained
by its creator or any successors, also known as the upstream code, and that may
happen for various reasons, which I will not go too much further into here,
however, to put it directly: this code associated with the package will most
likely have its regular upstream maintainers, with a lot of them also accepting
contributions from people that might use this software, care about its wellbeing
or even…its security, and the source code in an Ubuntu package will be nothing
more than a copy of an upstream version that is being contributed to by the
Ubuntu teams and the Ubuntu community. Very much in the holiday spirit, one of
the ideas of open source is to have people collaborate on software, as well as
have software be shared with those that wish to use it, sometimes with changes.
Moving on…on the other side of our coin, we have non-open source software,
also known as closed source software, which is software for which the source
code is not publicly available for all to inspect, use or modify. Closed source
software has its source code protected, with only an authorized group of
people - who are usually a part of the organization that developed said software
or that is currently maintaining it after taking responsibility for it at a
certain point in time - having access to this source code, be it to change the
source code or to simply look at it and know what it is. Closed software is
usually not free to use and users that wish to have access to the software and
its functionalities will only be able to obtain a final executable version of
it, where it is very difficult to acquire information on the source…unless you
are very determined, but more on that later. For now, know that closed source
software will allow you to execute it, but you can’t know what you are executing
unless you do some very intense digging. As for an example…let’s put it this
way, so that you can fill in the blanks: if Ubuntu is a door and the doors are
open, then that must mean that the Windows are … . And there you have your
answer. I mean…it is the holiday season and we would rather have our guests
come in to celebrate through the door instead of any other way. And I say this
because I want you to understand that there is no right or wrong when it comes
to open source and closed source, there are only preferences and needs. There
are situations where one will be more useful than the other, or where one might
be preferred over the other. Who am I to judge if you let people into your house
through your window, or your chimney? What actually matters to us here is: why
is closed source usually considered something more secure “intuitively” when
open source can be just as, or arguably, even more secure? So, let’s try to
answer that question, shall we? When you think about wanting to protect
something, you think about keeping it hidden, keeping it a secret. Wait…this
is not nearly festive enough for a holiday episode. Let’s try again. When you
don’t want someone to guess what is going to be the surprise holiday dessert you
are serving by the end of dinner, you usually won’t tell them anything about
it. You will hide the recipe, cook your dessert following that recipe, but only
allow your guests to know what it is and eat it once the time is just
right. After all, the holidays are all about each family’s tradition, and I know
dessert eating schedules are definitely a part of it for many. Anyway, the point
here is…if no one knows what the dessert is and they don’t have access to your
house while you cook it, bake it, prepare it in general, they cannot copy this
recipe to bring their own version of your dessert to your holiday celebration -
or any other holiday celebration, for that matter - and they can only speculate
on the ingredients once they eat it. And…since you kept your ingredients and
your cooking utensils far away from messy hands while you prepared your dessert,
no one can tamper with it, maybe steal a little bite before it is actually
complete, or even add a missing ingredient without authorization. You keep your
dessert “safe” by actually hiding it, allowing people access only when the final
product is complete. As much as I love holiday season analogies, let’s put our
cyber security glasses back on and see this situation from the closed source
point of view: your recipe is your source code; you preparing the dessert is you
editing, building and compiling the code to create an executable program; and
this executable program is actually your final holiday dessert.
You’re not sharing your source code, meaning people cannot tamper with it,
cannot create a bad copy of it and cannot inspect it in order to figure out
possible failures or ways to exploit it. Yes, even I have fallen victim to the
“too much sugar” mistake when baking stuff, but sometimes we can try to mask
mistakes with other ingredients and no one will ever know…This can also be
called security through obscurity, when you rely on secrecy and confidentiality
in order to avoid the exposure of weaknesses and the direct targeting that may
befall your software. How can a hacker actually exploit my code if they don’t
know what the code is? That is the idea behind security through obscurity. I
will not get into the details of whether security through obscurity is an
effective practice or not, because that is a very intense and polarizing
subject, and it is the holiday season…let’s leave the heated discussions for
some other time. I will say, however, that it directly clashes with the open
source premise, and it is one of the reasons that may be behind the choice of
making software closed source. However, even though this might be a way to
protect your software from exploitation and from vulnerability discovery, it is
not a fool proof technique to avoid the really determined from figuring out what
they want when they are trying to hack you. Talking once more about desserts,
because they are delicious and a very pleasing analogy to consider…if you
have, for example, a friend or family member that is a chef. They go to your
holiday dinner party and then eat your dessert, which we will consider here as
being a beautiful multilayered trifle. They eat your trifle and because they are
so experienced in the art of cooking, they are able to tell all of the
ingredients you have in your cream after tasting it. It is not a skill everyone
possesses - discovering the trifle recipe is no trifle matter…one might say -
and it is not something everyone will be looking forward to do…after all, some
of us simply want to eat and enjoy the food, be the ingredients what they
may. However, there might just be that someone that is willing and capable to go
the extra mile to figure out your recipe…and let me tell you the bad
news…there is not much you can do about it, because there is not much you can
hide about your dessert if you intend to serve it for people to eat.
The same goes for code. Yes, it is possible to not share the source code of your
software, but for a computer to run a software, it needs to follow the
instructions that were transformed into the executable program that originated
from the source code. So even if the executable does not contain the exact
source code, it will contain something that can be extracted and analyzed by the
brave and patient. Any program out there can be reverse engineered into its low
level code version, and this low level code, mainly created to be machine
readable code, when analyzed, will tell you more about what the source code
could actually be. You are able to get from the final product to the actual
recipe that led you to that product…even if the low level code will be very
difficult to analyze and piece together in order to form something similar to
what would be the original source code that generated it. But doubt not my
friend…there are people out there that are willing to do this, and sometimes
these people can be really, really good at it. So that is why security through
obscurity can help, as it is one more barrier that a hacker needs to cross in
order to be able to possibly tamper with a system, however, it is not an
impenetrable one, and it will only stop those lazy enough to cross it…or those
that maybe ate too much during dinner already and will pass on dessert.
Aah, holiday season food is delicious, isn’t it? Plus, I’m not the type to pass
on dessert, and I am definitely not done talking about them, the holiday spirit
and how it all relates to open source code quite yet, so let’s keep going. Hold
on to that dessert analogy, because we will bring it back shortly. For now, we
move on, understanding one reason why it might seem that closed source is safer
or more secure than open source. Especially when you think about one of the main
activities performed by the Ubuntu Security team, which is applying patches to
vulnerabilities that are constantly being found in the source code of packages
that can be installed in Ubuntu, or that are found in the core of Ubuntu, the
kernel. Throughout all the seasons, including the holiday season, we fix issues
that are being found by people from the community that look into and identify
flaws in these packages, sometimes even unintentionally. We can see this as
people finding problems with our recipe and pointing them out to us, forcing us
to change it so that the end result will be something better, something that all
can enjoy. “Hey, you have peanuts here, what about the people who have peanut
allergies that will eat this?”…or…“Hey, if this is cooked in the southern
hemisphere, where it is hot during the holiday season instead of cold, this rest
time for the cream might be too much and it will be too much of a liquid by the
time you want to put your trifle in its final container”. And while you listen
to all these complaints and look at your recipe book, you might think it is all
very annoying…having to change your recipe to fix all these problems…but
when you actually think about it…is it not helpful instead? I mean…you don’t
wanna kill grandma because you forgot she was allergic to peanuts, do you? Had
you not made your recipe public, you might have not discovered that you had to
change it…the bad way: by having grandma spit that trifle all over the floor
and scold you because grandma might fall for phishing scams from time to time,
but she knows better than to eat hidden peanuts in your trifle. Also…this is a
podcast with positive vibes, so let’s not actually consider the worst of the
worst situation here for grandma and for you as well… but you get the point.
Do not kid yourself by thinking that closed source software has less bugs than
open source software. They might be encountered at a smaller rate, since
analysis of the source code is something harder to do and can only be done by
people with access to the code, however, they are there…and sometimes, people
figure this out in the worst way possible: when they have already been
hacked. And then it is a race to figure out where the bug that caused the issue
is, so that it can be fixed. By making the source code public, people that are
willing to help and are willing to make this code better, safer and more robust
have the chance to actively participate in its development and improve the
overall final product. One of the reasons why open source software came to be
was exactly to provide users with more security, since it is easier to find
hidden problems in that which has a lot of people auditing AND it is also easier
to trust that which you can audit. Imagine if your prankster cousin wants to
tamper with your dessert, and they add an extra bad ingredient to the recipe
without your knowledge after you leave them a while with your recipe
book…after all, you also need to prepare your holiday dinner. Anyway, if you
had decided to hide your dessert recipe from everyone, people would only know
something was incredibly wrong once they would have eaten it. Of course, if you
were hiding it from everyone, you would have also hidden it from your prankster
cousin and not shown them the recipe in the first place, but they could have
just as easily found another way to get to it, and if they did a good job
changing the recipe without your knowledge, you might not even know it had been
tampered with at all. Shoutout to a well known comedy series in which someone
adds some savory food to what is supposed to be a dessert trifle because they
thought that was the correct recipe, when it was actually all a
misunderstanding. The ones who know, will know… Of course, when you hide your
recipe book well enough, it is not expected that the recipe will be tampered
with, but sometimes, you yourself are the one doing the tampering…you holiday
prankster, you! You want to play a prank on your friends and family during the
holidays and decide to add something weird to your dessert. If your recipe is
public, however, people are able to check for mistakes, and if they see
something that might be a problem to them, they can tell you so that you can fix
it, or they can choose to not eat your dessert if you don’t want to act on your
apparent mistake. Sure, if you make your recipe public maybe you don’t get to do
the prank - which is actually not really nice on your part, considering that you
are hosting a holiday party to entertain people you love and care about - but if
you don’t make it public, there might be people who just won’t eat your dessert
out of lack of trust in you.
When we talk about source code, we have the same. Being able to check the source
code for a program you wish to use will allow you to check if the source code is
doing something you don’t see as being secure, or if it is behaving insecurely
due to a bug. You can even create your own copy of the source with the changes
you find are necessary in order to get to use the software in a way you find
acceptable! However, since the code is public and a lot of people end up using
it, a community usually builds around it and there are always the ones looking
to improve code, fix its bugs, and make it more secure overall, so maybe you
won’t even need your own edited copy of the source code, since you can just
share your concerns with that community and the issue might be addressed
directly in the upstream version of the code. Of course this all depends if the
software you are considering has an active upstream and is being properly
maintained…that is unfortunately a downside to free and open source software:
not all code out there is being properly taken care of…not everyone has the
holiday spirit and wants to improve on their dessert recipes. They write it once
and just make it available to whoever wants to cook it without any extra
additions or mistake corrections. However, fear not, because at least when we
are talking about security, information regarding vulnerabilities found in open
source code is mostly shared publicly, and, since it is possible to have your
own copy of the code to edit, people who have these copies can also edit their
own versions to fix issues that were found by other people, be it with their own
fixes be it with fixes provided by the upstream developers that maintain the
software (when they exist)…as we do with Ubuntu packages! So as you can see,
open source truly encompasses the holiday spirit, by allowing people to share
and by allowing software to improve under the suggestions of many people. The
open source community being a group of friends sitting together to share that
holiday dinner, find possible issues and solve them so that next year said
dinner can be even more delicious…and maybe even have some extra desserts!
So there you have it, the reason why you don’t need to worry about open source
being insecure just because the source code is public. Sure, there is a risk
involved with having your code be public, but I had a teacher that once taught
me that sometimes it is not about hiding the algorithm, but instead about making
it that the algorithm is so well structured that it doesn’t matter that said
algorithm is public, since there is simply no way to exploit it. The basic
example are the cryptographic algorithms out there that we use to encrypt our
data: the algorithms are public, since we need a standard and people need to
know how things work in order to implement the standard and use it in their
applications, however, it doesn’t matter that they are public and that people
know the steps necessary to encrypt or decrypt some plain text, because what
matters is that if there is no key, breaking the encryption is simply not
achievable in our average lifespan with the average resources. The power of the
algorithm is in the way it works, the math and the theory that support it, and
not in its visibility. Everyone can look at the algorithm, and its security
stands strong. So without that key, breaking encryption is nearly
impossible. When writing open source code, the idea is to follow this same
premise: write good code, in such a way that it doesn’t matter that it is
public, because even if it is, it is not exploitable since you programmed it
with security in mind. So no…please don’t hardcode passwords into your open
source code. That is not secure practice, and that is not open source being
secure. Don’t do it in your closed source code…because this is not closed
source being secure also!
Strive to write a dessert recipe that is so perfect, that it doesn’t matter if
someone tries to tamper with it once it is completed, your dessert will come out
delicious every time! Yeah, I see you prankster cousin, trying to turn on the
heat to get my trifle to melt. It won’t though because I added gelatine to
it…or whatever ingredient is needed to not have cream melt…I’m not a cooking
expert…my family and friends definitely know that. Anyway, of course there are
problems that you might still come across even when cooking or coding with
deliciousness and security in mind. Because there is no dessert that can be
saved by you using 3kg of salt instead of 3g of salt on what is supposed to be
something sweet, because there is an accidental extra ‘k’ in your recipe…but
you get the point, and open source gets the point! Because if your dessert
recipe is an open recipe and someone finds this “accidental” 3kgs-of-salt
mistake - which happens, we are all human and we make mistakes - they can tell
you about it and you can fix it! So buy a recipe notebook that can be left
outside and no one can write on it unless they use the special notebook pen
which you own the rights to, sign your instructions so that you know which ones
are trustworthy, and fix the mistakes you find along the way when people that
want to share this amazing thing with you give you a nudge about it. You will
then know that you are doing your best to provide people with the best holiday
dessert ever, so that everyone can enjoy it together during this special holiday
time! Also…you know…secure open source code during the holidays as well!
Well, dearest friends and family, that is all of the holiday spirit I have to
share with you today! I wish you all an amazing holiday season, filled with
love, joy, open source and lots and lots of security patches! Feel free to share
your thoughts about this podcast segment and the topic related to it in any of
our social media channels! I hope you enjoyed it, and for now, I bid you all
farewell, and until next time! Bye!
Credit to https://www.fesliyanstudios.com for the background music.
Ubuntu Security team and podcast on holiday break [34:37]
Get in contact
View all episodes
By Ubuntu Security Team
4.8
1010 ratings
Overview
For our final episode of 2022, Camila is back with a special holiday themed
discussion of the security of open source code, plus we hint at what is in store
for the podcast for 2023 and we cover some recent security updates including
Python, PostgreSQL, Squid and more.
This week in Ubuntu Security Updates
54 unique CVEs addressed
[USN-5765-1] PostgreSQL vulnerability [00:55]
been established
[USN-5766-1] Heimdal vulnerability [01:38]
[USN-5768-1] GNU C Library vulnerabilities [01:47]
on untrusted input
[USN-5767-1, USN-5767-2] Python vulnerabilities [02:24]
applications - ie. unicode / bidirectional in your domain names) - used an
algorithm that was quadratic [O(n²)] - so if an attacker provided a really
long domain name that included crafted bidirectional unicode contents to be
parsed by the client, could cause the client to use lots of CPU resources to
parse this - this code was used by the socket and asyncio modules - and so
simply returning a 3xx redirect header with a crafted Location could trigger
this bug
true but this code was implemented in C
[USN-5769-1] protobuf vulnerabilities [03:56]
[USN-5770-1] GCC vulnerability
[USN-5771-1] Squid regression [04:05]
this was just a logging issue but turns out it was a real bug - an off-by-one
issue would mean squid would sometimes file to find items that were already
cached - only applies where the HTTP server is using the Vary header
[USN-5772-1] QEMU vulnerabilities [05:18]
[USN-5754-2, USN-5756-3] Linux kernel (Azure) vulnerabilities [05:39]
[USN-5754-1] Linux kernel
vulnerabilities - Buffer overflow in NFSD
[USN-5773-1] Linux kernel (OEM) vulnerabilities [06:14]
from GPZ discussed in the last 2 episodes
[USN-5774-1] Linux kernel (Azure) vulnerabilities [06:59]
[USN-5775-1] Vim vulnerabilities [07:18]
bounty program, found via fuzzing
[USN-5776-1] containerd vulnerabilities [08:07]
[USN-5777-1] Pillow vulnerabilities
Goings on in Ubuntu Security Community
Camila discusses the security of open source vs proprietary code [08:38]
Transcript
Hello listener! It has been a while since I last showed up here to share with
you some of my thoughts and spread the knowledge, and today I am back in order
to try to fix that, remove the void I have left in the hearts of those that
enjoy listening to me rambling about a certain cyber security topic. That being
said, I recorded my first podcast segment during the holiday season last year,
and I thought it would be very poetic to return at the same time this year to
record once again. Especially after I was struck with inspiration after spending
a little time with my family. Nothing more fitting for this once again holiday
episode, considering it is the time of the year - the most wonderful one - when
we usually enjoy mingling and celebrating with family and friends. The time of
the year where we meet in order to eat some good food, spend some quality time
together, catch up on life, share the joy… and answer the always asked
question by someone who knows you work with computers: “Do you think it’s a
virus?”. “Yes, uncle, it probably is, since the link you clicked on that said
‘Free 1000 dollar Christmas vouchers for the first 10 clicks’ is most likely a
scam. But hey, I gotta go now, because it is time for some delicious holiday
season desserts! Your computer can survive a few more hours doing some
cryptomining for some random hacker, so I’ll check on that later for you”.
Anyway, surprising as it may be, this actually was not the topic of conversation
that brought me here today, although I fully expect the previously mentioned
question to come my way whenever I do meet my family for the end of the year
festivities of 2022. Instead, I was asked a question that would probably have my
holiday treats wait for me a little bit longer, since it is one I find
compelling to answer, and one that I thought would be actually interesting to
share the answer to, so that you can take it to your holiday meetings as a hot
topic of conversation…you know…show off a little bit to the ones you love.
So…to elaborate a little bit more on my story and on this so far mysterious
question…while sipping on some delicious cocoa surrounded by some fairy lights
and the cold air - even though it is summer during the end of the year where I
live…I see you, southern hemisphere. I was traveling when this happened - my
dearest not-in-the-IT-field family member asked me the following question while
we had a conversation about my job: “how is it possible to have security in a
software when the code for that software is available for all to see on the
Internet?”. Running a prettify function on this question, we can word it as:
“how can open source software be secure if the code is public?”. And that,
family and friends, is the question that we wish to answer today. I already
answered my family member, but now, I want to do it the fancy way, the holiday
spirit way! So gather around with your drinks and delicious appetizers, and
before we head for dinner, and of course, dessert, let’s think about the year we
leave behind, the code that was a part of it, and why, in the year of 2022, can
this code be secure when everyone knows exactly what it is.
Let’s begin this beautiful holiday sharing moment by actually talking about what
is open source software and what is NOT open source software, as well as why one
would think that the former is less secure than the latter. To keep it simple:
open source software is the kind of software where the source code, a.k.a. the
instructions that will be transformed into the computer program that you will
later use, is publicly available for all to see. Those that wish to do so can
inspect this software’s code to know exactly how it does what it does. They can
use it freely if following its license terms, and they can even modify it, maybe
change its functionalities, be it through creation of a copy of that code that
branches from the original version, or be it with authorization from the
creator/maintainer of the software to edit the original version wherever it is
being maintained. A beautiful example to bring this all together in your mind:
almost all software packages in Ubuntu are open source. The programs you run in
your Ubuntu OS come from code that is publicly available for all to access
through the loveliest Internet. For many packages, it is possible to choose one
from main or universe, for example, and find its code in a repository after a
quick web search. Even quicker: you can download the source code related to the
executables and libraries apt installs in your Ubuntu OS when you run ‘apt-get
install ’ by running ‘apt-get source
’ instead. Please remember to replace
with the actual package name if you’re gonna try to
do this. Anyway, this package you download with apt may have its code differ a
little bit from the original code for that software package, the one maintained
by its creator or any successors, also known as the upstream code, and that may
happen for various reasons, which I will not go too much further into here,
however, to put it directly: this code associated with the package will most
likely have its regular upstream maintainers, with a lot of them also accepting
contributions from people that might use this software, care about its wellbeing
or even…its security, and the source code in an Ubuntu package will be nothing
more than a copy of an upstream version that is being contributed to by the
Ubuntu teams and the Ubuntu community. Very much in the holiday spirit, one of
the ideas of open source is to have people collaborate on software, as well as
have software be shared with those that wish to use it, sometimes with changes.
Moving on…on the other side of our coin, we have non-open source software,
also known as closed source software, which is software for which the source
code is not publicly available for all to inspect, use or modify. Closed source
software has its source code protected, with only an authorized group of
people - who are usually a part of the organization that developed said software
or that is currently maintaining it after taking responsibility for it at a
certain point in time - having access to this source code, be it to change the
source code or to simply look at it and know what it is. Closed software is
usually not free to use and users that wish to have access to the software and
its functionalities will only be able to obtain a final executable version of
it, where it is very difficult to acquire information on the source…unless you
are very determined, but more on that later. For now, know that closed source
software will allow you to execute it, but you can’t know what you are executing
unless you do some very intense digging. As for an example…let’s put it this
way, so that you can fill in the blanks: if Ubuntu is a door and the doors are
open, then that must mean that the Windows are … . And there you have your
answer. I mean…it is the holiday season and we would rather have our guests
come in to celebrate through the door instead of any other way. And I say this
because I want you to understand that there is no right or wrong when it comes
to open source and closed source, there are only preferences and needs. There
are situations where one will be more useful than the other, or where one might
be preferred over the other. Who am I to judge if you let people into your house
through your window, or your chimney? What actually matters to us here is: why
is closed source usually considered something more secure “intuitively” when
open source can be just as, or arguably, even more secure? So, let’s try to
answer that question, shall we? When you think about wanting to protect
something, you think about keeping it hidden, keeping it a secret. Wait…this
is not nearly festive enough for a holiday episode. Let’s try again. When you
don’t want someone to guess what is going to be the surprise holiday dessert you
are serving by the end of dinner, you usually won’t tell them anything about
it. You will hide the recipe, cook your dessert following that recipe, but only
allow your guests to know what it is and eat it once the time is just
right. After all, the holidays are all about each family’s tradition, and I know
dessert eating schedules are definitely a part of it for many. Anyway, the point
here is…if no one knows what the dessert is and they don’t have access to your
house while you cook it, bake it, prepare it in general, they cannot copy this
recipe to bring their own version of your dessert to your holiday celebration -
or any other holiday celebration, for that matter - and they can only speculate
on the ingredients once they eat it. And…since you kept your ingredients and
your cooking utensils far away from messy hands while you prepared your dessert,
no one can tamper with it, maybe steal a little bite before it is actually
complete, or even add a missing ingredient without authorization. You keep your
dessert “safe” by actually hiding it, allowing people access only when the final
product is complete. As much as I love holiday season analogies, let’s put our
cyber security glasses back on and see this situation from the closed source
point of view: your recipe is your source code; you preparing the dessert is you
editing, building and compiling the code to create an executable program; and
this executable program is actually your final holiday dessert.
You’re not sharing your source code, meaning people cannot tamper with it,
cannot create a bad copy of it and cannot inspect it in order to figure out
possible failures or ways to exploit it. Yes, even I have fallen victim to the
“too much sugar” mistake when baking stuff, but sometimes we can try to mask
mistakes with other ingredients and no one will ever know…This can also be
called security through obscurity, when you rely on secrecy and confidentiality
in order to avoid the exposure of weaknesses and the direct targeting that may
befall your software. How can a hacker actually exploit my code if they don’t
know what the code is? That is the idea behind security through obscurity. I
will not get into the details of whether security through obscurity is an
effective practice or not, because that is a very intense and polarizing
subject, and it is the holiday season…let’s leave the heated discussions for
some other time. I will say, however, that it directly clashes with the open
source premise, and it is one of the reasons that may be behind the choice of
making software closed source. However, even though this might be a way to
protect your software from exploitation and from vulnerability discovery, it is
not a fool proof technique to avoid the really determined from figuring out what
they want when they are trying to hack you. Talking once more about desserts,
because they are delicious and a very pleasing analogy to consider…if you
have, for example, a friend or family member that is a chef. They go to your
holiday dinner party and then eat your dessert, which we will consider here as
being a beautiful multilayered trifle. They eat your trifle and because they are
so experienced in the art of cooking, they are able to tell all of the
ingredients you have in your cream after tasting it. It is not a skill everyone
possesses - discovering the trifle recipe is no trifle matter…one might say -
and it is not something everyone will be looking forward to do…after all, some
of us simply want to eat and enjoy the food, be the ingredients what they
may. However, there might just be that someone that is willing and capable to go
the extra mile to figure out your recipe…and let me tell you the bad
news…there is not much you can do about it, because there is not much you can
hide about your dessert if you intend to serve it for people to eat.
The same goes for code. Yes, it is possible to not share the source code of your
software, but for a computer to run a software, it needs to follow the
instructions that were transformed into the executable program that originated
from the source code. So even if the executable does not contain the exact
source code, it will contain something that can be extracted and analyzed by the
brave and patient. Any program out there can be reverse engineered into its low
level code version, and this low level code, mainly created to be machine
readable code, when analyzed, will tell you more about what the source code
could actually be. You are able to get from the final product to the actual
recipe that led you to that product…even if the low level code will be very
difficult to analyze and piece together in order to form something similar to
what would be the original source code that generated it. But doubt not my
friend…there are people out there that are willing to do this, and sometimes
these people can be really, really good at it. So that is why security through
obscurity can help, as it is one more barrier that a hacker needs to cross in
order to be able to possibly tamper with a system, however, it is not an
impenetrable one, and it will only stop those lazy enough to cross it…or those
that maybe ate too much during dinner already and will pass on dessert.
Aah, holiday season food is delicious, isn’t it? Plus, I’m not the type to pass
on dessert, and I am definitely not done talking about them, the holiday spirit
and how it all relates to open source code quite yet, so let’s keep going. Hold
on to that dessert analogy, because we will bring it back shortly. For now, we
move on, understanding one reason why it might seem that closed source is safer
or more secure than open source. Especially when you think about one of the main
activities performed by the Ubuntu Security team, which is applying patches to
vulnerabilities that are constantly being found in the source code of packages
that can be installed in Ubuntu, or that are found in the core of Ubuntu, the
kernel. Throughout all the seasons, including the holiday season, we fix issues
that are being found by people from the community that look into and identify
flaws in these packages, sometimes even unintentionally. We can see this as
people finding problems with our recipe and pointing them out to us, forcing us
to change it so that the end result will be something better, something that all
can enjoy. “Hey, you have peanuts here, what about the people who have peanut
allergies that will eat this?”…or…“Hey, if this is cooked in the southern
hemisphere, where it is hot during the holiday season instead of cold, this rest
time for the cream might be too much and it will be too much of a liquid by the
time you want to put your trifle in its final container”. And while you listen
to all these complaints and look at your recipe book, you might think it is all
very annoying…having to change your recipe to fix all these problems…but
when you actually think about it…is it not helpful instead? I mean…you don’t
wanna kill grandma because you forgot she was allergic to peanuts, do you? Had
you not made your recipe public, you might have not discovered that you had to
change it…the bad way: by having grandma spit that trifle all over the floor
and scold you because grandma might fall for phishing scams from time to time,
but she knows better than to eat hidden peanuts in your trifle. Also…this is a
podcast with positive vibes, so let’s not actually consider the worst of the
worst situation here for grandma and for you as well… but you get the point.
Do not kid yourself by thinking that closed source software has less bugs than
open source software. They might be encountered at a smaller rate, since
analysis of the source code is something harder to do and can only be done by
people with access to the code, however, they are there…and sometimes, people
figure this out in the worst way possible: when they have already been
hacked. And then it is a race to figure out where the bug that caused the issue
is, so that it can be fixed. By making the source code public, people that are
willing to help and are willing to make this code better, safer and more robust
have the chance to actively participate in its development and improve the
overall final product. One of the reasons why open source software came to be
was exactly to provide users with more security, since it is easier to find
hidden problems in that which has a lot of people auditing AND it is also easier
to trust that which you can audit. Imagine if your prankster cousin wants to
tamper with your dessert, and they add an extra bad ingredient to the recipe
without your knowledge after you leave them a while with your recipe
book…after all, you also need to prepare your holiday dinner. Anyway, if you
had decided to hide your dessert recipe from everyone, people would only know
something was incredibly wrong once they would have eaten it. Of course, if you
were hiding it from everyone, you would have also hidden it from your prankster
cousin and not shown them the recipe in the first place, but they could have
just as easily found another way to get to it, and if they did a good job
changing the recipe without your knowledge, you might not even know it had been
tampered with at all. Shoutout to a well known comedy series in which someone
adds some savory food to what is supposed to be a dessert trifle because they
thought that was the correct recipe, when it was actually all a
misunderstanding. The ones who know, will know… Of course, when you hide your
recipe book well enough, it is not expected that the recipe will be tampered
with, but sometimes, you yourself are the one doing the tampering…you holiday
prankster, you! You want to play a prank on your friends and family during the
holidays and decide to add something weird to your dessert. If your recipe is
public, however, people are able to check for mistakes, and if they see
something that might be a problem to them, they can tell you so that you can fix
it, or they can choose to not eat your dessert if you don’t want to act on your
apparent mistake. Sure, if you make your recipe public maybe you don’t get to do
the prank - which is actually not really nice on your part, considering that you
are hosting a holiday party to entertain people you love and care about - but if
you don’t make it public, there might be people who just won’t eat your dessert
out of lack of trust in you.
When we talk about source code, we have the same. Being able to check the source
code for a program you wish to use will allow you to check if the source code is
doing something you don’t see as being secure, or if it is behaving insecurely
due to a bug. You can even create your own copy of the source with the changes
you find are necessary in order to get to use the software in a way you find
acceptable! However, since the code is public and a lot of people end up using
it, a community usually builds around it and there are always the ones looking
to improve code, fix its bugs, and make it more secure overall, so maybe you
won’t even need your own edited copy of the source code, since you can just
share your concerns with that community and the issue might be addressed
directly in the upstream version of the code. Of course this all depends if the
software you are considering has an active upstream and is being properly
maintained…that is unfortunately a downside to free and open source software:
not all code out there is being properly taken care of…not everyone has the
holiday spirit and wants to improve on their dessert recipes. They write it once
and just make it available to whoever wants to cook it without any extra
additions or mistake corrections. However, fear not, because at least when we
are talking about security, information regarding vulnerabilities found in open
source code is mostly shared publicly, and, since it is possible to have your
own copy of the code to edit, people who have these copies can also edit their
own versions to fix issues that were found by other people, be it with their own
fixes be it with fixes provided by the upstream developers that maintain the
software (when they exist)…as we do with Ubuntu packages! So as you can see,
open source truly encompasses the holiday spirit, by allowing people to share
and by allowing software to improve under the suggestions of many people. The
open source community being a group of friends sitting together to share that
holiday dinner, find possible issues and solve them so that next year said
dinner can be even more delicious…and maybe even have some extra desserts!
So there you have it, the reason why you don’t need to worry about open source
being insecure just because the source code is public. Sure, there is a risk
involved with having your code be public, but I had a teacher that once taught
me that sometimes it is not about hiding the algorithm, but instead about making
it that the algorithm is so well structured that it doesn’t matter that said
algorithm is public, since there is simply no way to exploit it. The basic
example are the cryptographic algorithms out there that we use to encrypt our
data: the algorithms are public, since we need a standard and people need to
know how things work in order to implement the standard and use it in their
applications, however, it doesn’t matter that they are public and that people
know the steps necessary to encrypt or decrypt some plain text, because what
matters is that if there is no key, breaking the encryption is simply not
achievable in our average lifespan with the average resources. The power of the
algorithm is in the way it works, the math and the theory that support it, and
not in its visibility. Everyone can look at the algorithm, and its security
stands strong. So without that key, breaking encryption is nearly
impossible. When writing open source code, the idea is to follow this same
premise: write good code, in such a way that it doesn’t matter that it is
public, because even if it is, it is not exploitable since you programmed it
with security in mind. So no…please don’t hardcode passwords into your open
source code. That is not secure practice, and that is not open source being
secure. Don’t do it in your closed source code…because this is not closed
source being secure also!
Strive to write a dessert recipe that is so perfect, that it doesn’t matter if
someone tries to tamper with it once it is completed, your dessert will come out
delicious every time! Yeah, I see you prankster cousin, trying to turn on the
heat to get my trifle to melt. It won’t though because I added gelatine to
it…or whatever ingredient is needed to not have cream melt…I’m not a cooking
expert…my family and friends definitely know that. Anyway, of course there are
problems that you might still come across even when cooking or coding with
deliciousness and security in mind. Because there is no dessert that can be
saved by you using 3kg of salt instead of 3g of salt on what is supposed to be
something sweet, because there is an accidental extra ‘k’ in your recipe…but
you get the point, and open source gets the point! Because if your dessert
recipe is an open recipe and someone finds this “accidental” 3kgs-of-salt
mistake - which happens, we are all human and we make mistakes - they can tell
you about it and you can fix it! So buy a recipe notebook that can be left
outside and no one can write on it unless they use the special notebook pen
which you own the rights to, sign your instructions so that you know which ones
are trustworthy, and fix the mistakes you find along the way when people that
want to share this amazing thing with you give you a nudge about it. You will
then know that you are doing your best to provide people with the best holiday
dessert ever, so that everyone can enjoy it together during this special holiday
time! Also…you know…secure open source code during the holidays as well!
Well, dearest friends and family, that is all of the holiday spirit I have to
share with you today! I wish you all an amazing holiday season, filled with
love, joy, open source and lots and lots of security patches! Feel free to share
your thoughts about this podcast segment and the topic related to it in any of
our social media channels! I hope you enjoyed it, and for now, I bid you all
farewell, and until next time! Bye!
Credit to https://www.fesliyanstudios.com for the background music.
Ubuntu Security team and podcast on holiday break [34:37]
Get in contact