OverviewFor our final episode of 2022, Camila is back with a special holiday themeddiscussion of the security of open source code, plus we hint at what is in storefor the podcast for 2023 and we cover some recent security updates includingPython, PostgreSQL, Squid and more.
This week in Ubuntu Security Updates54 unique CVEs addressed
[USN-5765-1] PostgreSQL vulnerability [00:55]* 1 CVEs addressed in Xenial ESM (16.04 ESM) + CVE-2021-23222 * [USN-5145-1] PostgreSQL vulnerabilities in Episode 138 * Akin to STARTTLS vulns - could inject cleartext before a secure connection hasbeen established
[USN-5766-1] Heimdal vulnerability [01:38]* 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS) + CVE-2022-41916 * Buffer over-read of 1 byte with crafted certificate - crash
[USN-5768-1] GNU C Library vulnerabilities [01:47]* 4 CVEs addressed in Xenial ESM (16.04 ESM) + CVE-2017-12132 + CVE-2020-27618 + CVE-2019-25013 + CVE-2016-10228 * Various possible crasher bugs in low-level utils that are not expected to runon untrusted input
[USN-5767-1, USN-5767-2] Python vulnerabilities [02:24]* 2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
+ CVE-2022-45061
+ CVE-2022-37454
* 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
+ CVE-2022-45061
* CPU based DoS when parsing IDNA (internationalised domain names inapplications - ie. unicode / bidirectional in your domain names) - used analgorithm that was quadratic [O(n²)] - so if an attacker provided a reallylong domain name that included crafted bidirectional unicode contents to beparsed by the client, could cause the client to use lots of CPU resources toparse this - this code was used by the socket and asyncio modules - and sosimply returning a 3xx redirect header with a crafted Location could triggerthis bug
* Possible integer overflow in SHA3 implementation - but python is memory safe -true but this code was implemented in C
[USN-5769-1] protobuf vulnerabilities [03:56]* 2 CVEs addressed in Xenial ESM (16.04 ESM) + CVE-2022-1941 + CVE-2015-5237
[USN-5770-1] GCC vulnerability* 1 CVEs addressed in Xenial ESM (16.04 ESM) + CVE-2017-11671
[USN-5771-1] Squid regression [04:05]* 6 CVEs addressed in Xenial ESM (16.04 ESM)
+ CVE-2018-1000027
+ CVE-2018-1000024
+ CVE-2016-3948
+ CVE-2016-2571
+ CVE-2016-2570
+ CVE-2016-2569
* Very old update to squid introduced a possible regression - initially thoughtthis was just a logging issue but turns out it was a real bug - an off-by-oneissue would mean squid would sometimes file to find items that were alreadycached - only applies where the HTTP server is using the Vary header
[USN-5772-1] QEMU vulnerabilities [05:18]* 6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10) + CVE-2022-3165 + CVE-2022-2962 + CVE-2022-0216 + CVE-2021-3930 + CVE-2021-3750 + CVE-2021-3682 * Various guest to host issues - allowing a guest to crash QEMU on the host
[USN-5754-2, USN-5756-3] Linux kernel (Azure) vulnerabilities [05:39]* 8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Kinetic (22.10) + CVE-2022-3621 + CVE-2022-3594 + CVE-2022-3567 + CVE-2022-3566 + CVE-2022-3565 + CVE-2022-3564 + CVE-2022-3524 + CVE-2022-43945 * 5.19 for 22.10, 5.4 for 20.04 LTS + 18.04 LTS * Most interesting is the high priority one we mentioned last week -[USN-5754-1] Linux kernelvulnerabilities - Buffer overflow in NFSD
[USN-5773-1] Linux kernel (OEM) vulnerabilities [06:14]* 10 CVEs addressed in Jammy (22.04 LTS) + CVE-2022-3621 + CVE-2022-3594 + CVE-2022-3567 + CVE-2022-3566 + CVE-2022-3564 + CVE-2022-3524 + CVE-2022-33743 + CVE-2022-26365 + CVE-2022-42703 + CVE-2022-43945 * 5.17 * Essentially the same as above but also includes the anonymous VMA mapping vulnfrom GPZ discussed in the last 2 episodes
[USN-5774-1] Linux kernel (Azure) vulnerabilities [06:59]* 16 CVEs addressed in Trusty ESM (14.04 ESM), Bionic (18.04 LTS) + CVE-2022-40768 + CVE-2022-36879 + CVE-2022-3635 + CVE-2022-3621 + CVE-2022-3594 + CVE-2022-3567 + CVE-2022-3566 + CVE-2022-3565 + CVE-2022-3564 + CVE-2022-3524 + CVE-2022-3239 + CVE-2022-3028 + CVE-2022-2978 + CVE-2022-2153 + CVE-2022-20422 + CVE-2022-42703 * 4.15
[USN-5775-1] Vim vulnerabilities [07:18]* 6 CVEs addressed in Xenial ESM (16.04 ESM) + CVE-2022-3591 + CVE-2022-3324 + CVE-2022-3256 + CVE-2022-3099 + CVE-2022-2581 + CVE-2022-2345 * Moar vim CVEs - none of these are high impact - all reported via their bugbounty program, found via fuzzing
[USN-5776-1] containerd vulnerabilities [08:07]* 4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10) + CVE-2022-24778 + CVE-2022-24769 + CVE-2022-31030 + CVE-2022-23471
[USN-5777-1] Pillow vulnerabilities* 2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS) + CVE-2022-45198 + CVE-2022-24303
Goings on in Ubuntu Security CommunityCamila discusses the security of open source vs proprietary code [08:38]TranscriptHello listener! It has been a while since I last showed up here to share withyou some of my thoughts and spread the knowledge, and today I am back in orderto try to fix that, remove the void I have left in the hearts of those thatenjoy listening to me rambling about a certain cyber security topic. That beingsaid, 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 torecord once again. Especially after I was struck with inspiration after spendinga little time with my family. Nothing more fitting for this once again holidayepisode, considering it is the time of the year - the most wonderful one - whenwe usually enjoy mingling and celebrating with family and friends. The time ofthe year where we meet in order to eat some good food, spend some quality timetogether, catch up on life, share the joy… and answer the always askedquestion by someone who knows you work with computers: “Do you think it’s avirus?”. “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 ascam. But hey, I gotta go now, because it is time for some delicious holidayseason desserts! Your computer can survive a few more hours doing somecryptomining 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 conversationthat brought me here today, although I fully expect the previously mentionedquestion to come my way whenever I do meet my family for the end of the yearfestivities of 2022. Instead, I was asked a question that would probably have myholiday treats wait for me a little bit longer, since it is one I findcompelling to answer, and one that I thought would be actually interesting toshare the answer to, so that you can take it to your holiday meetings as a hottopic 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 mysteriousquestion…while sipping on some delicious cocoa surrounded by some fairy lightsand the cold air - even though it is summer during the end of the year where Ilive…I see you, southern hemisphere. I was traveling when this happened - mydearest not-in-the-IT-field family member asked me the following question whilewe had a conversation about my job: “how is it possible to have security in asoftware when the code for that software is available for all to see on theInternet?”. 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 alreadyanswered my family member, but now, I want to do it the fancy way, the holidayspirit way! So gather around with your drinks and delicious appetizers, andbefore we head for dinner, and of course, dessert, let’s think about the year weleave behind, the code that was a part of it, and why, in the year of 2022, canthis code be secure when everyone knows exactly what it is.
Let’s begin this beautiful holiday sharing moment by actually talking about whatis open source software and what is NOT open source software, as well as why onewould 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. theinstructions that will be transformed into the computer program that you willlater use, is publicly available for all to see. Those that wish to do so caninspect this software’s code to know exactly how it does what it does. They canuse it freely if following its license terms, and they can even modify it, maybechange its functionalities, be it through creation of a copy of that code thatbranches from the original version, or be it with authorization from thecreator/maintainer of the software to edit the original version wherever it isbeing 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 inyour Ubuntu OS come from code that is publicly available for all to accessthrough the loveliest Internet. For many packages, it is possible to choose onefrom main or universe, for example, and find its code in a repository after aquick web search. Even quicker: you can download the source code related to theexecutables and libraries apt installs in your Ubuntu OS when you run ‘apt-getinstall
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 sourcecode is not publicly available for all to inspect, use or modify. Closed sourcesoftware has its source code protected, with only an authorized group ofpeople - who are usually a part of the organization that developed said softwareor that is currently maintaining it after taking responsibility for it at acertain point in time - having access to this source code, be it to change thesource code or to simply look at it and know what it is. Closed software isusually not free to use and users that wish to have access to the software andits functionalities will only be able to obtain a final executable version ofit, where it is very difficult to acquire information on the source…unless youare very determined, but more on that later. For now, know that closed sourcesoftware will allow you to execute it, but you can’t know what you are executingunless you do some very intense digging. As for an example…let’s put it thisway, so that you can fill in the blanks: if Ubuntu is a door and the doors areopen, then that must mean that the Windows are … . And there you have youranswer. I mean…it is the holiday season and we would rather have our guestscome in to celebrate through the door instead of any other way. And I say thisbecause I want you to understand that there is no right or wrong when it comesto open source and closed source, there are only preferences and needs. Thereare situations where one will be more useful than the other, or where one mightbe preferred over the other. Who am I to judge if you let people into your housethrough your window, or your chimney? What actually matters to us here is: whyis closed source usually considered something more secure “intuitively” whenopen source can be just as, or arguably, even more secure? So, let’s try toanswer that question, shall we? When you think about wanting to protectsomething, you think about keeping it hidden, keeping it a secret. Wait…thisis not nearly festive enough for a holiday episode. Let’s try again. When youdon’t want someone to guess what is going to be the surprise holiday dessert youare serving by the end of dinner, you usually won’t tell them anything aboutit. You will hide the recipe, cook your dessert following that recipe, but onlyallow your guests to know what it is and eat it once the time is justright. After all, the holidays are all about each family’s tradition, and I knowdessert eating schedules are definitely a part of it for many. Anyway, the pointhere is…if no one knows what the dessert is and they don’t have access to yourhouse while you cook it, bake it, prepare it in general, they cannot copy thisrecipe to bring their own version of your dessert to your holiday celebration -or any other holiday celebration, for that matter - and they can only speculateon the ingredients once they eat it. And…since you kept your ingredients andyour 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 actuallycomplete, or even add a missing ingredient without authorization. You keep yourdessert “safe” by actually hiding it, allowing people access only when the finalproduct is complete. As much as I love holiday season analogies, let’s put ourcyber security glasses back on and see this situation from the closed sourcepoint of view: your recipe is your source code; you preparing the dessert is youediting, building and compiling the code to create an executable program; andthis 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 outpossible 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 maskmistakes with other ingredients and no one will ever know…This can also becalled security through obscurity, when you rely on secrecy and confidentialityin order to avoid the exposure of weaknesses and the direct targeting that maybefall your software. How can a hacker actually exploit my code if they don’tknow what the code is? That is the idea behind security through obscurity. Iwill not get into the details of whether security through obscurity is aneffective practice or not, because that is a very intense and polarizingsubject, and it is the holiday season…let’s leave the heated discussions forsome other time. I will say, however, that it directly clashes with the opensource premise, and it is one of the reasons that may be behind the choice ofmaking software closed source. However, even though this might be a way toprotect your software from exploitation and from vulnerability discovery, it isnot a fool proof technique to avoid the really determined from figuring out whatthey 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 youhave, for example, a friend or family member that is a chef. They go to yourholiday dinner party and then eat your dessert, which we will consider here asbeing a beautiful multilayered trifle. They eat your trifle and because they areso experienced in the art of cooking, they are able to tell all of theingredients you have in your cream after tasting it. It is not a skill everyonepossesses - 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, someof us simply want to eat and enjoy the food, be the ingredients what theymay. However, there might just be that someone that is willing and capable to gothe extra mile to figure out your recipe…and let me tell you the badnews…there is not much you can do about it, because there is not much you canhide 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 yoursoftware, but for a computer to run a software, it needs to follow theinstructions that were transformed into the executable program that originatedfrom the source code. So even if the executable does not contain the exactsource code, it will contain something that can be extracted and analyzed by thebrave and patient. Any program out there can be reverse engineered into its lowlevel code version, and this low level code, mainly created to be machinereadable code, when analyzed, will tell you more about what the source codecould actually be. You are able to get from the final product to the actualrecipe that led you to that product…even if the low level code will be verydifficult to analyze and piece together in order to form something similar towhat would be the original source code that generated it. But doubt not myfriend…there are people out there that are willing to do this, and sometimesthese people can be really, really good at it. So that is why security throughobscurity can help, as it is one more barrier that a hacker needs to cross inorder to be able to possibly tamper with a system, however, it is not animpenetrable one, and it will only stop those lazy enough to cross it…or thosethat 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 passon dessert, and I am definitely not done talking about them, the holiday spiritand how it all relates to open source code quite yet, so let’s keep going. Holdon to that dessert analogy, because we will bring it back shortly. For now, wemove on, understanding one reason why it might seem that closed source is saferor more secure than open source. Especially when you think about one of the mainactivities performed by the Ubuntu Security team, which is applying patches tovulnerabilities that are constantly being found in the source code of packagesthat can be installed in Ubuntu, or that are found in the core of Ubuntu, thekernel. Throughout all the seasons, including the holiday season, we fix issuesthat are being found by people from the community that look into and identifyflaws in these packages, sometimes even unintentionally. We can see this aspeople finding problems with our recipe and pointing them out to us, forcing usto change it so that the end result will be something better, something that allcan enjoy. “Hey, you have peanuts here, what about the people who have peanutallergies that will eat this?”…or…“Hey, if this is cooked in the southernhemisphere, where it is hot during the holiday season instead of cold, this resttime for the cream might be too much and it will be too much of a liquid by thetime you want to put your trifle in its final container”. And while you listento all these complaints and look at your recipe book, you might think it is allvery annoying…having to change your recipe to fix all these problems…butwhen you actually think about it…is it not helpful instead? I mean…you don’twanna kill grandma because you forgot she was allergic to peanuts, do you? Hadyou not made your recipe public, you might have not discovered that you had tochange it…the bad way: by having grandma spit that trifle all over the floorand 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 apodcast with positive vibes, so let’s not actually consider the worst of theworst 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 thanopen source software. They might be encountered at a smaller rate, sinceanalysis of the source code is something harder to do and can only be done bypeople with access to the code, however, they are there…and sometimes, peoplefigure this out in the worst way possible: when they have already beenhacked. And then it is a race to figure out where the bug that caused the issueis, so that it can be fixed. By making the source code public, people that arewilling to help and are willing to make this code better, safer and more robusthave the chance to actively participate in its development and improve theoverall final product. One of the reasons why open source software came to bewas exactly to provide users with more security, since it is easier to findhidden problems in that which has a lot of people auditing AND it is also easierto trust that which you can audit. Imagine if your prankster cousin wants totamper with your dessert, and they add an extra bad ingredient to the recipewithout your knowledge after you leave them a while with your recipebook…after all, you also need to prepare your holiday dinner. Anyway, if youhad decided to hide your dessert recipe from everyone, people would only knowsomething was incredibly wrong once they would have eaten it. Of course, if youwere hiding it from everyone, you would have also hidden it from your prankstercousin and not shown them the recipe in the first place, but they could havejust as easily found another way to get to it, and if they did a good jobchanging the recipe without your knowledge, you might not even know it had beentampered with at all. Shoutout to a well known comedy series in which someoneadds some savory food to what is supposed to be a dessert trifle because theythought that was the correct recipe, when it was actually all amisunderstanding. The ones who know, will know… Of course, when you hide yourrecipe book well enough, it is not expected that the recipe will be tamperedwith, but sometimes, you yourself are the one doing the tampering…you holidayprankster, you! You want to play a prank on your friends and family during theholidays and decide to add something weird to your dessert. If your recipe ispublic, however, people are able to check for mistakes, and if they seesomething that might be a problem to them, they can tell you so that you can fixit, or they can choose to not eat your dessert if you don’t want to act on yourapparent mistake. Sure, if you make your recipe public maybe you don’t get to dothe prank - which is actually not really nice on your part, considering that youare hosting a holiday party to entertain people you love and care about - but ifyou don’t make it public, there might be people who just won’t eat your dessertout of lack of trust in you.
When we talk about source code, we have the same. Being able to check the sourcecode for a program you wish to use will allow you to check if the source code isdoing something you don’t see as being secure, or if it is behaving insecurelydue to a bug. You can even create your own copy of the source with the changesyou find are necessary in order to get to use the software in a way you findacceptable! However, since the code is public and a lot of people end up usingit, a community usually builds around it and there are always the ones lookingto improve code, fix its bugs, and make it more secure overall, so maybe youwon’t even need your own edited copy of the source code, since you can justshare your concerns with that community and the issue might be addresseddirectly in the upstream version of the code. Of course this all depends if thesoftware you are considering has an active upstream and is being properlymaintained…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 theholiday spirit and wants to improve on their dessert recipes. They write it onceand just make it available to whoever wants to cook it without any extraadditions or mistake corrections. However, fear not, because at least when weare talking about security, information regarding vulnerabilities found in opensource code is mostly shared publicly, and, since it is possible to have yourown copy of the code to edit, people who have these copies can also edit theirown versions to fix issues that were found by other people, be it with their ownfixes be it with fixes provided by the upstream developers that maintain thesoftware (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 shareand by allowing software to improve under the suggestions of many people. Theopen source community being a group of friends sitting together to share thatholiday dinner, find possible issues and solve them so that next year saiddinner 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 sourcebeing insecure just because the source code is public. Sure, there is a riskinvolved with having your code be public, but I had a teacher that once taughtme that sometimes it is not about hiding the algorithm, but instead about makingit that the algorithm is so well structured that it doesn’t matter that saidalgorithm is public, since there is simply no way to exploit it. The basicexample are the cryptographic algorithms out there that we use to encrypt ourdata: the algorithms are public, since we need a standard and people need toknow how things work in order to implement the standard and use it in theirapplications, however, it doesn’t matter that they are public and that peopleknow the steps necessary to encrypt or decrypt some plain text, because whatmatters is that if there is no key, breaking the encryption is simply notachievable in our average lifespan with the average resources. The power of thealgorithm is in the way it works, the math and the theory that support it, andnot in its visibility. Everyone can look at the algorithm, and its securitystands strong. So without that key, breaking encryption is nearlyimpossible. When writing open source code, the idea is to follow this samepremise: write good code, in such a way that it doesn’t matter that it ispublic, because even if it is, it is not exploitable since you programmed itwith security in mind. So no…please don’t hardcode passwords into your opensource code. That is not secure practice, and that is not open source beingsecure. Don’t do it in your closed source code…because this is not closedsource being secure also!
Strive to write a dessert recipe that is so perfect, that it doesn’t matter ifsomeone tries to tamper with it once it is completed, your dessert will come outdelicious every time! Yeah, I see you prankster cousin, trying to turn on theheat to get my trifle to melt. It won’t though because I added gelatine toit…or whatever ingredient is needed to not have cream melt…I’m not a cookingexpert…my family and friends definitely know that. Anyway, of course there areproblems that you might still come across even when cooking or coding withdeliciousness and security in mind. Because there is no dessert that can besaved by you using 3kg of salt instead of 3g of salt on what is supposed to besomething sweet, because there is an accidental extra ‘k’ in your recipe…butyou get the point, and open source gets the point! Because if your dessertrecipe is an open recipe and someone finds this “accidental” 3kgs-of-saltmistake - which happens, we are all human and we make mistakes - they can tellyou about it and you can fix it! So buy a recipe notebook that can be leftoutside and no one can write on it unless they use the special notebook penwhich you own the rights to, sign your instructions so that you know which onesare trustworthy, and fix the mistakes you find along the way when people thatwant to share this amazing thing with you give you a nudge about it. You willthen know that you are doing your best to provide people with the best holidaydessert ever, so that everyone can enjoy it together during this special holidaytime! 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 toshare with you today! I wish you all an amazing holiday season, filled withlove, joy, open source and lots and lots of security patches! Feel free to shareyour thoughts about this podcast segment and the topic related to it in any ofour social media channels! I hope you enjoyed it, and for now, I bid you allfarewell, 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]* Almost all of Canonical is on leave for 2 weeks * Various security team members will be in and out over the break - some taking more leave after that * Podcast will also take a break for a few weeks - likely return in late January * Hope to look at some changes / perhaps a more permanent co-host and other changes in 2023 * Wishing all our listeners a safe and enjoyable holiday season
Get in contact* security@ubuntu.com * #ubuntu-security on the Libera.Chat IRC network * ubuntu-hardened mailing list * Security section on discourse.ubuntu.com * @ubuntusecurity@fosstodon.org, @ubuntu_sec on twitter