Jump to content

Articles


wdfw w ff wdf sfsfd sfdwdfsdfwerw r werw erwe rwe rwer werwer werw erwer we r we rwerewrwe rwe rwer wer werwer werwe

A new security flaw has been identified in the sudo software. Sudo, which is installed by default in many operating systems, is by default setuid root. This means that any shortcomings can lead to local users being able to obtain root permissions.
Over the years, sudo has also become larger and more features have been added. This has i.a. led to OpenBSD now having an option called doas.
Yesterday, the American security company Qualys reported that they had identified a vulnerability in sudo (CVE-2021-3156). The vulnerability allows a local user to exploit a heap vulnerability and thus become rooted. The bug has been around since 2011 and is found in the standard configuration. It is important to point out that it is included in the standard configuration, as many vulnerabilities discovered in sudo require special configurations.
The vulnerability is found in the set_cmnd () function and can be most easily triggered by using sudoedit and the following command:
sudoedit -s '\' `perl -e 'print "A" x 65536'` And if you are vulnerable, you get a segfault. Please note that you need a local account but not a member of sudoers or similar. And that not all installations have sudoedit, such as macOS.
Video from Qualys showing vulnerability:
 
Kryptera.se
A new report from the security company RiskIQ inform of a new phishing kit that use JavaScript to manipulate the DOM, which allows for the script to dynamically alter the visible content and HTML form data within a page without user interaction.  This Phishing kit,  called LogoKit has seen a significant upswing in usage over the last month.
Phishing has been on the rise lately, following the increased usage of data communication in the wake of COVID-19. This new phishing kit seem to have attracted attention lately due to its flexibility and very fast application compared to building websites manually  as is the common practice.
This is both interesting and scary as it allows for very fast and dynamic application for bad elements and since it looks quite real and have your email already filled in, chances are that a lot of people will fall for this. Fortunately you often can see in the URL that something is not right. In LogoKit you can often see your email in the url, which look something like this:
phishingpage[.]site/login.html#victim@company.com Sadly this is not a sure way to detect  phishing attack as there are other ways to forward data, but if you see this then at least you know to look at the page you entered a bit more carefully.
LogoKit has seen a big increase in usage in the last month with over 700 unique domains running it. Targeted services range from generic login portals to false SharePoint portals, Adobe Document Cloud, OneDrive, Office 365, and interestingly enough Cryptocurrency exchanges. So be alert (as always) when accessing your external cloud services and portals.
 
RiskIQ have concluded that this is a threat on the rise due to it's simplicity and ease of use.
 
Jimi Wikman
My favorite E-commerce profile Katrin have purchased a competitor called SiteDirect and by doing so she now will be in charge of two popular platforms and 14 people in 3 locations. This is great news, and I am very happy that things are going well for Katrin and her husband Erik.
While I do not know much about SiteDirect I know it is an "old" and experienced company with a platform that has been popular for a long time. If Katrin is investing in SiteDirect, then you can bet she has looked at it from all angles and that means that the platform and the people are top of the line.
This is something I think is really good for both platforms as there are synergies that will benefit from this acquisition. Kodmyran are well known in Sweden for their excellent platform, the amazing technical skill from Erik and the development team and a ton of e-commerce knowledge and skill from Katrin and the whole team.
I look forward to seeing what this acquisition will mean for both platforms and what synergies we will see in the future.
Jimi Wikman
User Story Mapping is something that you probably have heard about if you work as product owner, business analyst or requirement analyst. It is a great tool for quickly break down customer journeys into system areas to map out work. The trick however is to use it where it is useful, which is in the business process when working with business analysis.
I often see people presenting User Story Mapping as a requirement tool, or even something that is useful for development as a backlog tool. This is usually suggested by business analysts and managers such as product owners, which makes sense because it is for them User Story Mapping is actually useful. Unfortunately it makes no sense for a developer since code are not following a customer journey.

For development, it is often very difficult to map things into a User Story Map. This is especially difficult for backend development where a lot of the work never even is seen by the end user. This causes some issues, not because User Story Mapping is bad in any way, but because it is defined on a user story level, when it is actually a process above the user story level.
For me this process is best used on the business side to map out features by the product owner and the Business Analyst. This is where the User Story Map truly shines, making it easy to understand where in the customer journey certain features live in a visual way. That is not to say that it has no value to a developer, quite the opposite. It is very useful to understand what feature you are working on and where it fit in the flow of things.
It is just not what is important for the development itself.
When it comes to the development itself you still want to have well-defined user stories in the form of work orders and acceptance criteria. Each user story also need to be small enough to be possible to complete within one increment (one sprint) and in most cases you will find that the user stories presented in the User Story Map are way too big for that.
I would actually suggest to not use the term user story mapping since that to me is misleading. I would instead call it User Feature Mapping to avoid confusion.
 
Try it!
You can use this purely analog by mapping up a customer journey on a white board and then use that with stickies, or you can take advantage of apps in Jira for example. My two favorites are Easy Agile User Story Maps for Jira by Easy Agile and Agile User Story Mapping Board for Jira by DevSamurai. Both are great tools that will give you the tools you need to get started with User Story Mapping.
 
 
Jimi Wikman
Developer Velocity Index, or DVI for short, is pushed hard by Microsoft right now as a way to sell Azure DevOps as I see it. So what is it and is it just another pointless measurement tool that does not address the big elephant in the room, or can it actually be useful? Let us dig into it and find out.
So Developer Velocity Index is a tool for measuring, well, quite a lot actually. At first glance we see a lot of focus on tools, which of course is the main goal for Microsoft as they need to get more clients for Azure Devops that is trying to challenge prominent actors such as Atlassian.
If you look a bit deeper however you will see that the DVI is pretty extensive. While focus is on tools it seems to look at these from a perspective that is not just focused on the development discipline. DVI claim to involve 46 different drivers across 13 dimensions and that is pretty good. I say claim because I have not tried this yet, so I do not know to what extent this is actually true.
 

 
The DVI is based on self-assessment through questionnaires, which is not a bad way to do this honestly. It will ensure that the introverts also get a say, which is not always the case in verbal situations where the extroverts are always loudest.
I see the tool angle a lot when reading about DVI, but when you dig down you see that what that almost always mean is that the tools in question bridge the gap between business and IT. Tools that help manage inflow, portfolio management and of course tools to help with clarifying need, especially in Agile teams. I think Tibi Covaci from Microsoft express this best:
I think this is profoundly true. Like my former colleague Eva Nordstrom would say "A fool with a tool is still a fool".  Good tools with a good and well-educated organization however, that will truly generate magic. It is my hope that DVI can help illustrate the need for organizational change to help facilitate that. This is often the biggest issue in my experience and one that is very hard to overcome.
It is also no big revelation that most organizations find the funnel between business and IT to be lacking or that this is where most organizations fail. The introduction of Agile often make this worse, which is not the fault of Agile, but the way it is implemented in organizations. Hopefully DVI can illustrate the need to have a proper portfolio management on the operative level and that even in Agile work teams you need to ensure that demands are evolved.
Ad-Hoc and shooting things from the hip are sure ways to make any developer sad after all, and we all want some form of structure to our chaos to ensure we know what to do, yet remain flexible...
Developer Velocity Index is interesting, but it is still a stick that should not be needed in mature organizations. Sadly there are very few mature organizations out there, so I think this is very interesting for many reasons. I will dig into it some more and see what I can learn.
What do you think?
Is it just a selling tool for more tools you don't need, or something that can drive actual change?
Jimi Wikman